Crash report (SASL) gives more or less where and why a bug happens. But is it possible to refine this (the function, the line de code, etc) ?
相关问题
- Is “new” in Erlang part of the official standard a
- how to create a keep-alive process in Erlang
- ejabberd and Erlang installation with lager_transf
- Encrypt (cryptojs) - Decrypt (erlang)
- How to use erlang-examples
相关文章
- How do I modify a record in erlang?
- Check active timers in Erlang
- undefined function maps:to_json/1
- How to convert datetime() to timestamp() in Erlang
- what good orm api will work well with scala or erl
- GC performance in Erlang
- When to “let it crash” and when to defend the code
- Intercept login/logout ejabberd
In general, no. The erlang .beam files does not contain the line numbers from the original code, so it is hard to know at what line the problem occurred. I do have a number of macros I use in my project, included as
"log.hrl"
:and this does give you some log lines in the program to hunt for. For debugging I often also use the redbug tool from the eper suite:
https://github.com/massemanet/eper
It allows you to trace in realtime whenever a call happens:
I hope this helps.
If you can reproduce the fault, the best way to get more information is to put a dbg trace on sections in question and review that output.
This usually does the trick for me. Replace Mod and Func with whatever module and function you want to debug.
If you are looking for more detailed post-mortem logging then sasl and the error_logger are your friends. There are of course times when SASL does not give you enough info, if this happens a lot in your system you probably should either learn to understand the SASL output better or write your own log handler. It is quite easy to plug-in your own error handler into SASL and output things as you want.
You will however never get line number as that information is destroyed at compilation time and there is no way for the VM to know which line crashed. It does however know which function and possibly with which arguments, given this it is usually possible to find out where things went wrong. Unless you write very long functions, which IMO is bad code smell and a sign that you should refactor your code to smaller functions.