<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div>Re: indentation: blame the Emacs mode which uses GNU style indents: X spaces, replace any consecutive 8 spaces by a hard tab. It's quite clever in fact but most tools (especially that damn GitHub) can't cope with it cleanly.<br><br>-- <div>Anthony Ramine</div></div><div><br>Le 31 oct. 2013 à 12:11, Pierre Fenoll <<a href="mailto:pierrefenoll@gmail.com">pierrefenoll@gmail.com</a>> a écrit :<br><br></div><blockquote type="cite"><div><div dir="ltr">There, nox: <a href="https://github.com/nox/otp/compare/better-error-reports">https://github.com/nox/otp/compare/better-error-reports</a><div>(BTW you seem to have a mix of tabs and spaces in your code)</div>
</div><div class="gmail_extra"><br clear="all"><div><div dir="ltr"><div><div><br></div><div>Cheers,</div><div>-- </div><div>Pierre Fenoll</div></div><div><br></div></div></div>
<br><br><div class="gmail_quote">On 31 October 2013 10:51, Anthony Ramine <span dir="ltr"><<a href="mailto:n.oxyde@gmail.com" target="_blank">n.oxyde@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Even if we sent a structured term to the error logger, we would need to limit its size because the error term and stack trace is copied on the error logger heap and can be very very huge.<br>
<br>
Shameless plug: my better-error-reports (IIRC the name, can't check right now) aims first to improve stack trace formatting and second to improve the terms sent to the error logger.<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
Anthony Ramine<br>
<br>
> Le 31 oct. 2013 à 11:27, Matthias Lang <<a href="mailto:matthias@corelatus.se">matthias@corelatus.se</a>> a écrit :<br>
</font></span><div class="HOEnZb"><div class="h5">><br>
> Hi,<br>
><br>
> TLDR: Whenever an Erlang process dies an abnormal death, there's some<br>
> code deep in the VM which sends an unstructured message to<br>
> error_logger about the death. This was surprising to me.<br>
><br>
><br>
> The Question<br>
> ------------<br>
><br>
> I was going to ask "where does this 'ERROR REPORT' message come from?":<br>
><br>
> ~ >erl -boot start_sasl<br>
> Erlang R15B03 (erts-5.9.3.1)...<br>
> ...<br>
> 1> spawn(fun() -> 3 = 9 end).<br>
> <0.42.0><br>
> 2><br>
> =ERROR REPORT==== 31-Oct-2013::10:51:47 ===<br>
> Error in process <0.42.0> with exit value: {{badmatch,9},[{erl_eval,expr,3,[]}]}<br>
><br>
> But before asking, I dug out the answer myself. So this post is a<br>
> question with the answer supplied. Hope someone's interested.<br>
><br>
> Anyway, this "Error in process <0.42.0>" message, how can that<br>
> possibly work?<br>
><br>
><br>
> Impossible answers<br>
> ------------------<br>
><br>
> No Erlang process is linked to <0.42.0>---I used plain spawn()---so it<br>
> can't work through links.<br>
><br>
> No Erlang process is monitoring <0.42.0>, so that's out too.<br>
><br>
> I even checked that there's no tracing on. There isn't.<br>
><br>
> I can't find anything in the 'Barklund Draft' which says that abnormal<br>
> process death should give information to another process through any<br>
> other mechanism. So, this is a top secret part of Erlang, available<br>
> only to helmeted, blonde, bearded eaters of rotten fish.<br>
><br>
><br>
> The actual answer<br>
> -----------------<br>
><br>
> Deep in "beam_emu.c", there's terminate_proc(). Here's what it does:<br>
><br>
> erts_dsprintf_buf_t *dsbufp = erts_create_logger_dsbuf();<br>
> erts_dsprintf(dsbufp, "Error in process %T ", c_p->id);<br>
> erts_dsprintf(dsbufp,"with exit value: %0.*T\n", display_items, Value);<br>
> erts_send_error_to_logger(c_p->group_leader, dsbufp);<br>
><br>
> So, the exit value term, i.e. {badmatch, 9} and the stack trace is<br>
> turned into a string (!) and then sent to the process registered as<br>
> 'error_logger'.<br>
><br>
> It seems OTP invaded the Erlang VM a bit... The other times I've seen<br>
> the VM send messages to the error logger, it's because something's on<br>
> fire, e.g. distribution has gone nuts. Not something mundane like a<br>
> process dying. Seems like a quick hack left over from long ago.<br>
><br>
><br>
> The fix<br>
> -------<br>
><br>
> If you implement your own error_logger, it's tempting to match these<br>
> messages so you can do things with them---you might want to format<br>
> them differently, or someone might have a burning need to translate<br>
> them to Maori---but this is unpalatable because the message comes as a<br>
> string.<br>
><br>
> That leaves the approach taken by proc_lib:spawn(), which is to wrap<br>
> the spawned code in a 'try', which means the VM never gets its fingers<br>
> on that crash. And that then gets you back to what I expected: if I<br>
> spawn() a process, I want it to just die quietly, even if it<br>
> crashes. Shame that's not the default.<br>
><br>
> Matt<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>
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></div>
</div></blockquote></body></html>