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

[Bengt Kleberg]

The width of a tab, counted in number of spaces, should user
configurable.


bengt

On Thu, 2013-10-31 at 12:43 +0100, Anthony Ramine wrote:
> 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.
> 
> -- 
> Anthony Ramine
> 
> Le 31 oct. 2013 à 12:11, Pierre Fenoll <pierrefenoll@REDACTED> a
> écrit :
> 
> 
> > 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
> >         
> > 
> > 
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions