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

[Anthony Ramine]

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