[erlang-questions] An answer: how does SASL know that a process died?

[Pierre Fenoll]

There, nox: https://github.com/nox/otp/compare/better-error-reports
(BTW you seem to have a mix of tabs and spaces in your code)


Cheers,
-- 
Pierre Fenoll



On 31 October 2013 10:51, Anthony Ramine <n.oxyde@REDACTED> wrote:

> 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.
>
> 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.
>
> --
> Anthony Ramine
>
> > Le 31 oct. 2013 à 11:27, Matthias Lang <matthias@REDACTED> a écrit :
> >
> > Hi,
> >
> > TLDR: Whenever an Erlang process dies an abnormal death, there's some
> >      code deep in the VM which sends an unstructured message to
> >      error_logger about the death. This was surprising to me.
> >
> >
> > The Question
> > ------------
> >
> > I was going to ask "where does this 'ERROR REPORT' message come from?":
> >
> >   ~ >erl -boot start_sasl
> >   Erlang R15B03 (erts-5.9.3.1)...
> >   ...
> >   1> spawn(fun() -> 3 = 9 end).
> >   <0.42.0>
> >   2>
> >   =ERROR REPORT==== 31-Oct-2013::10:51:47 ===
> >   Error in process <0.42.0> with exit value:
> {{badmatch,9},[{erl_eval,expr,3,[]}]}
> >
> > But before asking, I dug out the answer myself. So this post is a
> > question with the answer supplied. Hope someone's interested.
> >
> > Anyway, this "Error in process <0.42.0>" message, how can that
> > possibly work?
> >
> >
> > Impossible answers
> > ------------------
> >
> > No Erlang process is linked to <0.42.0>---I used plain spawn()---so it
> > can't work through links.
> >
> > No Erlang process is monitoring <0.42.0>, so that's out too.
> >
> > I even checked that there's no tracing on. There isn't.
> >
> > I can't find anything in the 'Barklund Draft' which says that abnormal
> > process death should give information to another process through any
> > other mechanism. So, this is a top secret part of Erlang, available
> > only to helmeted, blonde, bearded eaters of rotten fish.
> >
> >
> > The actual answer
> > -----------------
> >
> > Deep in "beam_emu.c", there's terminate_proc(). Here's what it does:
> >
> >   erts_dsprintf_buf_t *dsbufp = erts_create_logger_dsbuf();
> >   erts_dsprintf(dsbufp, "Error in process %T ", c_p->id);
> >   erts_dsprintf(dsbufp,"with exit value: %0.*T\n", display_items, Value);
> >   erts_send_error_to_logger(c_p->group_leader, dsbufp);
> >
> > So, the exit value term, i.e. {badmatch, 9} and the stack trace is
> > turned into a string (!) and then sent to the process registered as
> > 'error_logger'.
> >
> > It seems OTP invaded the Erlang VM a bit... The other times I've seen
> > the VM send messages to the error logger, it's because something's on
> > fire, e.g. distribution has gone nuts. Not something mundane like a
> > process dying. Seems like a quick hack left over from long ago.
> >
> >
> > The fix
> > -------
> >
> > If you implement your own error_logger, it's tempting to match these
> > messages so you can do things with them---you might want to format
> > them differently, or someone might have a burning need to translate
> > them to Maori---but this is unpalatable because the message comes as a
> > string.
> >
> > That leaves the approach taken by proc_lib:spawn(), which is to wrap
> > the spawned code in a 'try', which means the VM never gets its fingers
> > on that crash. And that then gets you back to what I expected: if I
> > spawn() a process, I want it to just die quietly, even if it
> > crashes. Shame that's not the default.
> >
> > Matt
> > _______________________________________________
> > erlang-questions mailing list
> > erlang-questions@REDACTED
> > http://erlang.org/mailman/listinfo/erlang-questions
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20131031/ef16d33d/attachment.htm>