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) ?
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.
dbg:tracer(),dbg:p(all,c),dbg:tpl(Mod,Func,x).
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.
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":
-define(INFO(T), error_logger:info_report(T)).
-define(WARN(T), error_logger:warning_report(
[process_info(self(), current_function), {line, ?LINE} | T])).
-define(ERR(T), error_logger:error_report(
[process_info(self(), current_function), {line, ?LINE} | T])).
-define(DEBUG(Format, Args), io:format("D(~p:~p:~p) : "++Format++"~n",
[self(),?MODULE,?LINE]++Args)).
-define(DEBUGP(Args), io:format("D(~p:~p:~p) : ~p~n",
[self(),?MODULE,?LINE, Args])).
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:
Eshell V5.8.3 (abort with ^G)
1> redbug:start("erlang:now() -> stack;return", [{time, 60*1000}]).
ok
2> erlang:now().
{1297,183814,756227}
17:50:14 <{erlang,apply,2}> {erlang,now,[]}
shell:eval_loop/3
shell:eval_exprs/7
shell:exprs/7
17:50:14 <{erlang,apply,2}> {erlang,now,0} -> {1297,183814,756227}
3>
I hope this helps.
Related
Warning: erlang n00b ahead.
I'm trying to get a grasp of erlang, and just trying a basic hello world application with cowboy. I'm simulating an error, basically returning an invalid value somewhere in my code, and trying to interpret the error, which is:
=ERROR REPORT==== 11-Jul-2013::15:45:00 ===
Error in process <0.167.0> with exit value: {{try_clause,{ok, {http_req,#Port<0.3619>,ranch_tcp,keepalive,<0.167.0>,<<3 bytes>>,'HTTP/1.1', {{127,0,0,1},60312},<<9 bytes>>,undefined,8081,<<1 byte>>,undefined,<<0 bytes>>,undefined,[],[{<<10 bytes>>,<<11 bytes>>},{<<4 bytes>>,<<14 bytes>>},{<<6 bytes>>,<<3 bytes>>}],[],undefined,[],waiting,undefined,<<0 bytes>>,false,waiting,[],<<0 bytes>>,undefined}}}, [{cowboy_handler,handler_init,4,[...
I've setup my application with rebar, and I'm running it with:
erl -pa ebin deps/*/ebin -s myapp
As you can see, the error ends with "..." which makes me think it is being truncated. Is there any way to print the full report?
And, is there any way to make it pretty-print it?
Thanks!
What you see is sasl's tty handler. It formats and writes reports to console. During formatting it could cut some useful data.
To avoid it, use error_logger_mf_h handler like this:
Create app.config file to pass some vars to sasl:
[
{sasl, [
{sasl_error_logger, {file, "sasl.log"}},
{errlog_type, all},
{error_logger_mf_dir, "."}, % Log directory
{error_logger_mf_maxbytes, 10485760}, % 10 MB max file size
{error_logger_mf_maxfiles, 5} % 5 files max
]}
].
Then bring erl node with started sasl. Logs will be printed into sasl.log
erl -boot start_sasl -config app.config
The error message is truncated by the Erlang emulator, so there is no way to get the full message from sasl. There is an undocumented switch that you can use to see more of the message. "erl +# 400" truncate at 400 instead of 200 characters.
More details: http://erlang.org/pipermail/erlang-questions/2014-October/081442.html
I believe there is no easy way of telling sasl to not truncate the error report.
What you could do is create your own handler for the reports and log the error in a way that it is not truncated. (e.g. io:format("~p", [Error])).
Look here for an exemple of custom report handler.
And you must add your custom handler as a subscriber of error reports:
error_logger:add_report_handler(?MODULE, []).
Or you could use a logging library that supports error_logger.
I am trying to make a simple UDP packet decoder.
packet_decoder(Packet)->
<<Opts:8,MobIdLength:8,MobId:64,MobIdType:8,MgeType:8,SeqNum:16,Rest/binary>> = Packet,
io:format("Options:~p~n",Opts),
io:format("MobIdLength:~p~n",MobIdLength),
io:format("MobId:~p~n",MobId),
io:format("MobIdType:~p~n",MobIdType),
io:format("MgeType:~p~n",MgeType),
io:format("SeqNum:~p~n",SeqNum).
Packet is passed by a receive loop:
rcv_loop(Socket) ->
inet:setopts(Socket, [{active, once}, binary]),
io:format("rcvr started:~n"),
receive
{udp, Socket, Host, Port, Bin} ->
packet_decoder(Bin),
rcv_loop(Socket)
end.
I keep getting(following error edited 9/7/12 9:30 EST):
** exception error: no match of right hand side value
<<131,8,53,134,150,4,149,0,80,15,1,2,1,2,0,16,80,71,115,
52,80,71,115,53,24,63,227,197,211,...>>
in function udp_server:packet_decoder/1
called as udp_server:packet_decoder(<<131,8,53,134,150,4,149,0,80,15,
1,2,1,2,0,16,80,71,115,52,80,71,
115,53,24,63,227,197,...>>)
in call from udp_server:rcv_loop/1
in call from udp_server:init/0
If I create the same variable in the Erlang shell as a binary, i.e.
Packet = <<131,8,53,134,150,4,149,0,80,15,1,2,1,2,0,16,80,71,115,52,80,71,115,53,24,63,227,197,211,228,89,72,0,0,0,0,0,0,0,16,0,5,5,32,1,4,255,159,15,18,28,0,34,62,2,0,0,0,0,0,0,0,47,67>>.
<<Opts:8,MobIdLength:8,MobId:64,MobIdType:8,MgeType:8,SeqNum:16,Rest/binary>> = Packet.
It works just fine. Is there some subtlety in passing this to a function that I am missing? I have tried what I think is everything(except the right way). I tried setting the type and size. I also just tried
<<Rest/binary>> = Packet.
To no avail. Any help much appreciated.
The error you are getting when you run your code does not match your code. The error you are getting:
** exception error: no match of right hand side value ...
is a badmatch error and comes from an explicit = match where the pattern does not match the value from the RHS. There is no = in the code for rcv_loop/1. This implies that the loop you are running is not this code. So there are some questions to be asked:
When you have recompiled the module containing rcv_loop/1 have you restarted the loop so you run the new code? This is not done automagically.
Are you sure you are loading/running the code you think you are? I know this question sounds stupid but it is very easy, and not uncommon, to work on one version of the code and load another. You need to get the paths right.
The other things about mentioned about your code would not give this error. The calls to io:format/2 are wrong but would result in errors when you make the actual calls to io:format/2. Using the variable Socket as you do is not an error, it just means that you only want to receive UDP packets from just that socket.
EDIT : the first part of my answer was completely wrong so in order to not mislead, I deleted it.
Like spotted Alexey Kachayev io:format takes as second parameter a list, so :
packet_decoder(Packet)->
<<Opts:8,MobIdLength:8,MobId:64,MobIdType:8,MgeType:8,SeqNum:16,Rest/binary>> = Packet,
io:format("Options:~p~n",[Opts]),
io:format("MobIdLength:~p~n",[MobIdLength]),
io:format("MobId:~p~n",[MobId]),
io:format("MobIdType:~p~n",[MobIdType]),
io:format("MgeType:~p~n",[MgeType]),
io:format("SeqNum:~p~n",[SeqNum]).
I figured it out(kinda). I had been working on this in erlide in eclipse which had worked fine for all of the other parts of the. I tried compiling it from the erl shell and it worked fine. There must be some minor difference in the way eclipse is representing the source or the way it invokes the erlang compiler and shell. I will take it up with erlide.org. Thanks for the help!
This works in my erlang shell:
1> U = default_user_name().
2> crypto:start().
3> crypto:sha(U).
4> crypto:stop().
But when I compile this:
default_pw() ->
U = default_user_name(),
crypto:start(),
crypto:sha(U),
crypto:stop().
And execute it in the erlang shell, I get this:
1> person:default_pw().
** exception error: bad argument
in function port_control/3
called as port_control(crypto_drv04,5,<<"jDoe">>)
in call from crypto:control/2
Two questions:
1) What am I doing wrong?
2) It seems that I need to start and stop the crypto server. But is there a better place to start and stop it in my application?
Many thanks,
LRP
The error you are getting indicates that the crypto application was not started. An easy way to start it is just to add it as a parameter to erl like so:
$ erl -s crypto
I had a look at the current implementation of crypto and the past release notes for erlang and I came to the following conclusions (someone please correct me if I'm wrong):
Erlang releases <14A require crypto to be started prior to calling any functions because the library used a port driver. This makes sense because I got the error you described with 13B04 after not starting crypto.
Erlang releases >=14A don't require crypto to be started as the implementation now uses NIFs. This makes sense because the current implementation of crypto_server.erl is just a gen_server template, and on 14B03 I don't need to start the application in order to make crypto:sha/1 work.
I am trying to make Erlang's Inets mode_esi work and run some function. So, far, I did not succeed. Can someone post a minimal example of how to run Inets so that a url like http:localhost:8099/esi/my_mod:foo will invoke the method my_mod:foo/3?
Addition: I have started inets with these commands:
inets:start(),
inets:start(httpd, [{port, 8099}, {server_name, "localhost"}, {document_root, "."},
{server_root, "."}, {erl_script_alias, {"/esi", [my_esi, io]}}]).
The module is:
-module(my_esi).
-export([foo/3]).
foo(Sid, Env, In) -> mod_esi:deliver(Sid, ["bla"]).
But browsing to http://localhost:8099/esi/my_esi:foo result in an error message.
To clarify what has already been said, I'll give a working example (from the ground up). This is to help those who came here from google, mostly because it's how I found it ;)
First, create the module:
# filename: my_esi.erl
-module(my_esi).
-export([foo/3,bar/3]).
foo(Sid, Env, In) -> mod_esi:deliver(Sid, ["foo"]).
bar(Sid, Env, In) -> mod_esi:deliver(Sid, ["bar"]).
Save it, then compile it:
erlc my_esi.erl
You'll now have my_esi.beam
Then run the shell from bash
erl
Within the shell type the following:
inets:start().
{Httpd_State,Httpd_Pid} = inets:start(httpd, [{port, 8099}, {server_name, "localhost"}, {document_root, "."}, {modules,[mod_esi]},{server_root, "."}, {erl_script_alias, {"/esi", [my_esi, io]}}]).
The important part here is:
{modules,[mod_esi]}
If you need other modules, load them by appending them to the list.
To clarify how/why:
I will first admit that it does seems a bit strange at first, and that the documentation was less helpful than I had hoped. However, I realised that:
modules() -> [atom()]
becomes:
{modules, [mod_access, mod_esi, ..., etc.]}
Hope it helps someone :)
I've solved it myself. For some reason, beyond my understanding, the exact same code worked when I invoked Inets with a configuration file (a modified version of inets/examples/server_root/conf/8080.conf). I suppose that the example file includes a more complete list of properties that Inets required than what I listed in inets:start(httpd, [...]). If anyone encounters Inets problem in the future, my advice is to start with the example configuration.
Ok, here goes:
set {erl_script_alias, {"/esi", [my_mod]}} for the inets web server, so the module is accepted.
Write my_mod. Something like:
-module(my_mod).
-export([foo/3]).
foo(SessID, _Env, _Input) ->
mod_esi:deliver(SessID, ["Data ", <<"as">>, " an iolist"]).
Make sure mod_esi is part of inets section called module: {modules, [.., mod_esi, ..}}
This step is very important: Breathe 3 times, recite the holy words "I pray to thee, inets, that you will work this time". Cross your fingers.
Drink a cup of coffee. Tea will not do. It has to be coffee.
Enjoy your web server.
A common pattern in Erlang is the recursive loop that maintains state:
loop(State) ->
receive
Msg ->
NewState = whatever(Msg),
loop(NewState)
end.
Is there any way to query the state of a running process with a bif or tracing or something? Since crash messages say "...when state was..." and show the crashed process's state, I thought this would be easy, but I was disappointed that I haven't been able to find a bif to do this.
So, then, I figured using the dbg module's tracing would do it. Unfortunately, I believe because these loops are tail call optimized, dbg will only capture the first call to the function.
Any solution?
If your process is using OTP, it is enough to do sys:get_status(Pid).
The error message you mentions is displayed by SASL. SASL is an error reporting daemon in OTP.
The state you are referring in your example code is just an argument of tail recursive function. There is no way to extract it using anything except for tracing BIFs. I guess this would be not a proper solution in production code, since tracing is intended to be used only for debug purposes.
Proper, and industry tested, solution would be make extensive use of OTP in your project. Then you can take full advantage of SASL error reporting, rb module to collect these reports, sys - to inspect the state of the running OTP-compatible process, proc_lib - to make short-lived processes OTP-compliant, etc.
It turns out there's a better answer than all of these, if you're using OTP:
sys:get_state/1
Probably it didn't exist at the time.
It looks like you're making the problem out of nothing. erlang:process_info/1 gives enough information for debugging purposes. If your REALLY need loop function arguments, why don't you give it back to caller in response to one of the special messages that you define yourself?
UPDATE:
Just to clarify terminology. The closest thing to the 'state of the process' on the language level is process dictionary, usage of which is highly discouraged. It can be queried by erlang:process_info/1 or erlang:process/2.
What you actually need is to trace process's local functions calls along with their arguments:
-module(ping).
-export([start/0, send/1, loop/1]).
start() ->
spawn(?MODULE, loop, [0]).
send(Pid) ->
Pid ! {self(), ping},
receive
pong ->
pong
end.
loop(S) ->
receive
{Pid, ping} ->
Pid ! pong,
loop(S + 1)
end.
Console:
Erlang (BEAM) emulator version 5.6.5 [source] [smp:2] [async-threads:0] [kernel-poll:false]
Eshell V5.6.5 (abort with ^G)
1> l(ping).
{module,ping}
2> erlang:trace(all, true, [call]).
23
3> erlang:trace_pattern({ping, '_', '_'}, true, [local]).
5
4> Pid = ping:start().
<0.36.0>
5> ping:send(Pid).
pong
6> flush().
Shell got {trace,<0.36.0>,call,{ping,loop,[0]}}
Shell got {trace,<0.36.0>,call,{ping,loop,[1]}}
ok
7>
{status,Pid,_,[_,_,_,_,[_,_,{data,[{_,State}]}]]} = sys:get_status(Pid).
That's what I use to get the state of a gen_server. (Tried to add it as a comment to the reply above, but couldn't get formatting right.)
As far as I know you cant get the arguments passed to a locally called function. I would love for someone to prove me wrong.
-module(loop).
-export([start/0, loop/1]).
start() ->
spawn_link(fun () -> loop([]) end).
loop(State) ->
receive
Msg ->
loop([Msg|State])
end.
If we want to trace this module you do the following in the shell.
dbg:tracer().
dbg:p(new,[c]).
dbg:tpl(loop, []).
Using this tracing setting you get to see local calls (the 'l' in tpl means that local calls will be traced as well, not only global ones).
5> Pid = loop:start().
(<0.39.0>) call loop:'-start/0-fun-0-'/0
(<0.39.0>) call loop:loop/1
<0.39.0>
6> Pid ! foo.
(<0.39.0>) call loop:loop/1
foo
As you see, just the calls are included. No arguments in sight.
My recommendation is to base correctness in debugging and testing on the messages sent rather than state kept in processes. I.e. if you send the process a bunch of messages, assert that it does the right thing, not that it has a certain set of values.
But of course, you could also sprinkle some erlang:display(State) calls in your code temporarily. Poor man's debugging.
This is a "oneliner" That can be used in the shell.
sys:get_status(list_to_pid("<0.1012.0>")).
It helps you convert a pid string into a Pid.