That's nice to know, thanks Raimo :)<br><br><div class="gmail_quote">On Mon, Nov 28, 2011 at 5:33 PM, Raimo Niskanen <span dir="ltr"><<a href="mailto:raimo%2Berlang-questions@erix.ericsson.se">raimo+erlang-questions@erix.ericsson.se</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im">On Mon, Nov 28, 2011 at 05:13:17PM +0100, Ahmed Omar wrote:<br>
> It's kind of cheating, as it's not documented.(AFAIK)<br>
> x is euqal to<br>
> calling dbg:fun2ms(fun(_)-> exception_trace() end).<br>
> which generates MatchSpec :<br>
> [{'_',[],[{exception_trace}]}]<br>
><br>
> from documentation of match specs<br>
> <a href="http://www.erlang.org/doc/apps/erts/match_spec.html" target="_blank">http://www.erlang.org/doc/apps/erts/match_spec.html</a><br>
</div>> *exception_trace:* Same as *return_trace*, plus; if the traced function<br>
<div class="im">> exits due to an exception, anexception_from trace message is generated,<br>
> whether the exception is caught or not.<br>
<br>
</div>Well, if you try dbg:ltp() you will see all your saved match specs<br>
along with the "predefined" match specs, and this is actually<br>
documented in dbg.<br>
<br>
And, the predefined match specs will most probably not be removed<br>
nor changed. Not without very good reason.<br>
<br>
So it is not cheating.<br>
<br>
In a recent system you will also find predefined match specs<br>
with the short abbreviations 'c' and 'cx'. Have a look.<br>
<div><div class="h5"><br>
><br>
> example:<br>
> 37> dbg:tracer().<br>
> {ok,<0.85.0>}<br>
> 38> dbg:tpl(calendar, x).<br>
> {ok,[{matched,nonode@nohost,39},{saved,x}]}<br>
> 39> dbg:p(all,c).<br>
> {ok,[{matched,nonode@nohost,26}]}<br>
> 40> calendar:local_time_to_universal_time(33).<br>
> (<0.83.0>) call calendar:local_time_to_universal_time(33)<br>
> (<0.83.0>) exception_from {calendar,local_time_to_universal_time,1}<br>
> {error,badarg}<br>
> ** exception error: bad argument<br>
>      in function  erlang:localtime_to_universaltime/2<br>
>         called as erlang:localtime_to_universaltime(33,undefined)<br>
>      in call from erlang:localtime_to_universaltime/1<br>
><br>
><br>
> I think better use the documented form :)<br>
> dbg:tpl(usr_drv, dbg:fun2ms(fun(_)-> exception_trace() end)).<br>
><br>
><br>
> On Mon, Nov 28, 2011 at 4:38 PM, Kirill Zaborsky <<a href="mailto:qrilka@gmail.com">qrilka@gmail.com</a>> wrote:<br>
><br>
> > Ahmed, minor question: what does 'x' mean in dbg:tpl(user_drv, x) ? From<br>
> > the documentation I do not see what this match specification mya mean.<br>
> ><br>
> > Kind regards,<br>
> > Kirill Zaborsky<br>
> ><br>
> ><br>
> > 2011/11/28 Ahmed Omar <<a href="mailto:spawn.think@gmail.com">spawn.think@gmail.com</a>><br>
> ><br>
> >> Krill,<br>
> >> How about using some dbg?<br>
> >> Note : you need to be careful not to generate huge amount of debugging on<br>
> >> your node that could actually kill your node. I don't know much about your<br>
> >> system and how heavy the load on nodes is.<br>
> >><br>
> >> You can do something like :<br>
> >> dbg:tracer(port, dbg:trace_port(file, "/tmp/usr_drv.dbg")).<br>
> >> dbg:p(user_drv, [m, c]).<br>
> >> dbg:tpl(user_drv, x).<br>
> >><br>
> >> This way you will have a file that contains tracing of all messages and<br>
> >> local function calls done in process user_drv<br>
> >> When the node stuck we can see more details about what happened (note :<br>
> >> watch for the file size too)<br>
> >><br>
> >> On Mon, Nov 28, 2011 at 1:37 PM, Kirill Zaborsky <<a href="mailto:qrilka@gmail.com">qrilka@gmail.com</a>>wrote:<br>
> >><br>
> >>> Thanks, dennis,<br>
> >>> I have created a crash dump on a test machine (using halfword emulator)<br>
> >>> and received user_drv in waiting state with<br>
> >>> Program counter - 0x0000000002845f00 (user_drv:server_loop/5 + 48)<br>
> >>> So it's on the same instruction (but not running)<br>
> >>><br>
> >>> Disassembly shows:<br>
> >>> -----------------<br>
> >>> 0000000002845E80: i_func_info_IaaI 0 user_drv server_loop 5<br>
> >>> 0000000002845EA8: allocate_init_tIy 7 5 y(0)<br>
> >>> 0000000002845EC0: init_y y(1)<br>
> >>> 0000000002845ED0: move2_xyxy x(4) y(2) x(3) y(3)<br>
> >>> 0000000002845EE0: move2_xyxy x(2) y(4) x(1) y(5)<br>
> >>> 0000000002845EF0: move_ry x(0) y(6)<br>
> >>> 0000000002845F00: i_loop_rec_fr f(0000000002846C80) x(0)<br>
> >>> 0000000002845F10: i_select_tuple_arity2_rfAfAf x(0) f(0000000002846C40)<br>
> >>> 2 f(0000000002845F40) 3 f(0000000002846418)<br>
> >>> 0000000002845F40: i_get_tuple_element_rPx x(0) 0 x(1)<br>
> >>> .....<br>
> >>> 0000000002846C80: wait_f f(0000000002845F00)<br>
> >>> 0000000002846C90: badmatch_r x(0)<br>
> >>> -----------------<br>
> >>> So it's just a waiting loop. I don'see how the process could be running<br>
> >>> when the only ouput for some time was "ALIVE" messages every 15 minutes<br>
> >>> from run_erl.<br>
> >>> Loooks like the only way to see what was going on is to get complete<br>
> >>> crash dump, but it was truncated by heart :-\<br>
> >>><br>
> >>> P.S. It's quite strange that crash dump shows +48<br>
> >>><br>
> >>> 2011/11/28 <<a href="mailto:dennis.novikov@gmail.com">dennis.novikov@gmail.com</a>><br>
> >>><br>
> >>> +48 does not point to an instruction start on a couple of 32-bit systems<br>
> >>>> I have access to, so I can not assist you further.<br>
> >>>><br>
> >>>> To get instructions dump named "user_drv.dis" in the beam process<br>
> >>>> working directory you can do<br>
> >>>><br>
> >>>> erts_debug:df(user_drv).<br>
> >>>><br>
> >>>> Happy bug-hunting.<br>
> >>>><br>
> >>>><br>
> >>>><br>
> >>>> On Mon, 28 Nov 2011 12:01:17 +0200, Kirill Zaborsky <<a href="mailto:qrilka@gmail.com">qrilka@gmail.com</a>><br>
> >>>> wrote:<br>
> >>>><br>
> >>>>  I'm using halfword emulator on 64bit Ubuntu Server<br>
> >>>>> And the process state is not "waiting" but "running". Previous crash<br>
> >>>>> dumps<br>
> >>>>> show the same program counter value (and user_drv in running state)<br>
> >>>>><br>
> >>>>> Kind regards,<br>
> >>>>> Kirill Zaborsky<br>
> >>>>><br>
> >>>>><br>
> >>>>> 2011/11/28 Dennis Novikov <<a href="mailto:dennis.novikov@gmail.com">dennis.novikov@gmail.com</a>><br>
> >>>>><br>
> >>>>>  On Mon, 28 Nov 2011 08:44:42 +0200, Kirill Zaborsky <<a href="mailto:qrilka@gmail.com">qrilka@gmail.com</a><br>
> >>>>>> ><br>
> >>>>>> wrote:<br>
> >>>>>><br>
> >>>>>>  Trying to fins any workaround to this "stuck node" scenario I've<br>
> >>>>>> upgraded<br>
> >>>>>><br>
> >>>>>>> to R14B04 and turned on "heart".<br>
> >>>>>>> But recently  the node once again stopped responding. And heart did<br>
> >>>>>>> not<br>
> >>>>>>> assume it to be stuck although I could not contact it.<br>
> >>>>>>> I've tried to to get a crashdump with 'kill -USR1' but it appeared<br>
> >>>>>>> that<br>
> >>>>>>> once again crash dump was truncated. Does heart kills "dead" erlang<br>
> >>>>>>> node?<br>
> >>>>>>> And the only thing that could be seen from the crash dump that the<br>
> >>>>>>> only<br>
> >>>>>>> running process was user_drv (just like in previous times) with<br>
> >>>>>>> program<br>
> >>>>>>> counter equal to "user_drv:server_loop/5 + 48". Is it possible to<br>
> >>>>>>> find out<br>
> >>>>>>> what exactly does it stands for?<br>
> >>>>>>><br>
> >>>>>>><br>
> >>>>>> Waiting on receive in that function. And you are observing this on a<br>
> >>>>>> 32-bit VM.<br>
> >>>>>><br>
> >>>>>> --<br>
> >>>>>> WBR,<br>
> >>>>>>  DN<br>
> >>>>>><br>
> >>>>>><br>
> >>>><br>
> >>>> --<br>
> >>>> WBR,<br>
> >>>>  DN<br>
> >>>><br>
> >>><br>
> >>><br>
> >>> _______________________________________________<br>
> >>> erlang-questions mailing list<br>
> >>> <a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br>
> >>> <a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
> >>><br>
> >>><br>
> >><br>
> >><br>
> >> --<br>
> >> Best Regards,<br>
> >> - Ahmed Omar<br>
> >> <a href="http://nl.linkedin.com/in/adiaa" target="_blank">http://nl.linkedin.com/in/adiaa</a><br>
> >> Follow me on twitter<br>
</div></div>> >> @spawn_think <<a href="http://twitter.com/#!/spawn_think" target="_blank">http://twitter.com/#!/spawn_think</a>><br>
<div class="im">> >><br>
> >><br>
> ><br>
><br>
><br>
> --<br>
> Best Regards,<br>
> - Ahmed Omar<br>
> <a href="http://nl.linkedin.com/in/adiaa" target="_blank">http://nl.linkedin.com/in/adiaa</a><br>
> Follow me on twitter<br>
</div>> @spawn_think <<a href="http://twitter.com/#!/spawn_think" target="_blank">http://twitter.com/#!/spawn_think</a>><br>
<div class="im"><br>
> _______________________________________________<br>
> erlang-questions mailing list<br>
> <a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br>
> <a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
<br>
<br>
--<br>
<br>
</div>/ Raimo Niskanen, Erlang/OTP, Ericsson AB<br>
<div class="HOEnZb"><div class="h5">_______________________________________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br>Best Regards,<br>- Ahmed Omar<div><a href="http://nl.linkedin.com/in/adiaa" target="_blank">http://nl.linkedin.com/in/adiaa</a></div><div>Follow me on twitter</div>
<div><a href="http://twitter.com/#!/spawn_think" target="_blank">@spawn_think</a></div><br>