[erlang-questions] An answer: how does SASL know that a process died?
Bengt Kleberg
bengt.kleberg@REDACTED
Thu Oct 31 13:13:11 CET 2013
No debate. Just stating an opinion as a fact.
bengt
On Thu, 2013-10-31 at 12:58 +0100, Anthony Ramine wrote:
> Are we really going to debate this?
>
> I don’t want to, but I also don’t want to read people stating their opinion as if they were facts.
>
> --
> Anthony Ramine
>
> Le 31 oct. 2013 à 12:55, Bengt Kleberg <bengt.kleberg@REDACTED> a écrit :
>
> > 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
> >
> > _______________________________________________
> > erlang-questions mailing list
> > erlang-questions@REDACTED
> > http://erlang.org/mailman/listinfo/erlang-questions
>
More information about the erlang-questions
mailing list