An answer: how does SASL know that a process died?

classic Classic list List threaded Threaded
19 messages Options
Reply | Threaded
Open this post in threaded view
|

An answer: how does SASL know that a process died?

Matthias Lang-2
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

Reply | Threaded
Open this post in threaded view
|

An answer: how does SASL know that a process died?

Anthony Ramine-2
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> 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
> http://erlang.org/mailman/listinfo/erlang-questions

Reply | Threaded
Open this post in threaded view
|

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> 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> 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
> > http://erlang.org/mailman/listinfo/erlang-questions
> _______________________________________________
> erlang-questions mailing list
> erlang-questions
> 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.html>

Reply | Threaded
Open this post in threaded view
|

An answer: how does SASL know that a process died?

Anthony Ramine-2
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> 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> 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> 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
>> > http://erlang.org/mailman/listinfo/erlang-questions
>> _______________________________________________
>> erlang-questions mailing list
>> erlang-questions
>> http://erlang.org/mailman/listinfo/erlang-questions
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20131031/19cf03eb/attachment.html>

Reply | Threaded
Open this post in threaded view
|

An answer: how does SASL know that a process died?

Bengt Kleberg-4
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> 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> 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> 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
> >         > http://erlang.org/mailman/listinfo/erlang-questions
> >         _______________________________________________
> >         erlang-questions mailing list
> >         erlang-questions
> >         http://erlang.org/mailman/listinfo/erlang-questions
> >        
> >
> >
> _______________________________________________
> erlang-questions mailing list
> erlang-questions
> http://erlang.org/mailman/listinfo/erlang-questions


Reply | Threaded
Open this post in threaded view
|

An answer: how does SASL know that a process died?

Anthony Ramine-2
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> 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> 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> 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> 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
>>>> http://erlang.org/mailman/listinfo/erlang-questions
>>>        _______________________________________________
>>>        erlang-questions mailing list
>>>        erlang-questions
>>>        http://erlang.org/mailman/listinfo/erlang-questions
>>>
>>>
>>>
>> _______________________________________________
>> erlang-questions mailing list
>> erlang-questions
>> http://erlang.org/mailman/listinfo/erlang-questions
>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions
> http://erlang.org/mailman/listinfo/erlang-questions


Reply | Threaded
Open this post in threaded view
|

An answer: how does SASL know that a process died?

Richard Carlsson-5
In reply to this post by Matthias Lang-2
Yes, when a process terminates abnormally (including uncaught throw/1,
but not when terminating due to exit/1), a message is sent to the error
logger.  This was never described in the Barklund draft (very few people
knew that anything special happened in that situation), but I discovered
it when I was working on exceptions - see the end of section 2.7 in
http://www.erlang.se/workshop/2004/exception.pdf, and it affected how
the final try/catch construction and the classification of exceptions
had to work. We also took the opportunity to describe this behaviour in
section 2.8 of "Erlang and OTP in Action". I can't find anything about
it anywhere in the OTP docs.

On a language specification level, it's pretty unfortunate that OTP made
this hard connection between something as basic as exceptions and a
high-level feature like the error logger. And as you observed, the
format it's being sent on is not good either. I'm not sure if that can
be changed or if it needs to remain backwards compatible with existing
code out there.

     /Richard


On 2013-10-31 11:27 , Matthias Lang wrote:

> 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
> http://erlang.org/mailman/listinfo/erlang-questions
>


Reply | Threaded
Open this post in threaded view
|

An answer: how does SASL know that a process died?

Bengt Kleberg-4
In reply to this post by Anthony Ramine-2
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> 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> 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> 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> 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
> >>>> http://erlang.org/mailman/listinfo/erlang-questions
> >>>        _______________________________________________
> >>>        erlang-questions mailing list
> >>>        erlang-questions
> >>>        http://erlang.org/mailman/listinfo/erlang-questions
> >>>
> >>>
> >>>
> >> _______________________________________________
> >> erlang-questions mailing list
> >> erlang-questions
> >> http://erlang.org/mailman/listinfo/erlang-questions
> >
> > _______________________________________________
> > erlang-questions mailing list
> > erlang-questions
> > http://erlang.org/mailman/listinfo/erlang-questions
>


Reply | Threaded
Open this post in threaded view
|

An answer: how does SASL know that a process died?

Anthony Ramine-2
In reply to this post by Richard Carlsson-5
There is a way:

https://github.com/erlang/otp/blob/77bf7dfa0cc6d99c426d4057da8446dc51cea7aa/erts/emulator/beam/utils.c#L1648-1651

You can see in this code comment that what is actually sent is a format string and a list of args. We could add textual parts to the trivial "~s~n" format string and make the list of arguments more structured.

To handle the truncation of stack traces, I would use a first ref() argument which is ignored at the start of the format string and use that ref to identify "holes" in the copied terms, i.e. put that reference when copying where ?...? would have been printed previously. Clever depth arguments would make io continue to print ??? where these references will occur.

--
Anthony Ramine

Le 31 oct. 2013 ? 13:02, Richard Carlsson <carlsson.richard> a ?crit :

> I'm not sure if that can be changed or if it needs to remain backwards compatible with existing code out there.


Reply | Threaded
Open this post in threaded view
|

An answer: how does SASL know that a process died?

Robert Virding-5
In reply to this post by Richard Carlsson-5
What a stupid thing for the system to do! Erlang is Erlang and OTP is something on top of Erlang. It was never written into the spec because we didn't know about it. How can we get rid of it? It is definitely a bug, at best a bad design decision!

Robert

----- Original Message -----

> From: "Richard Carlsson" <carlsson.richard>
>
> Yes, when a process terminates abnormally (including uncaught throw/1,
> but not when terminating due to exit/1), a message is sent to the error
> logger.  This was never described in the Barklund draft (very few people
> knew that anything special happened in that situation), but I discovered
> it when I was working on exceptions - see the end of section 2.7 in
> http://www.erlang.se/workshop/2004/exception.pdf, and it affected how
> the final try/catch construction and the classification of exceptions
> had to work. We also took the opportunity to describe this behaviour in
> section 2.8 of "Erlang and OTP in Action". I can't find anything about
> it anywhere in the OTP docs.
>
> On a language specification level, it's pretty unfortunate that OTP made
> this hard connection between something as basic as exceptions and a
> high-level feature like the error logger. And as you observed, the
> format it's being sent on is not good either. I'm not sure if that can
> be changed or if it needs to remain backwards compatible with existing
> code out there.
>
>      /Richard
>
>
> On 2013-10-31 11:27 , Matthias Lang wrote:
> > 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
> > http://erlang.org/mailman/listinfo/erlang-questions
> >
>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions
> http://erlang.org/mailman/listinfo/erlang-questions
>

Reply | Threaded
Open this post in threaded view
|

An answer: how does SASL know that a process died?

Anthony Ramine-2
Would you get rid of error_handler too? Because I find that worse than the error_logger situation. At least a logger is just a logger, it can?t masquerade a function call as another one or do fancy things like this.

--
Anthony Ramine

Le 31 oct. 2013 ? 16:12, Robert Virding <robert.virding> a ?crit :

> What a stupid thing for the system to do! Erlang is Erlang and OTP is something on top of Erlang. It was never written into the spec because we didn't know about it. How can we get rid of it? It is definitely a bug, at best a bad design decision!


Reply | Threaded
Open this post in threaded view
|

An answer: how does SASL know that a process died?

Matthias Lang-2
In reply to this post by Robert Virding-5
Hi,

RC> I'm not sure if that can RC be changed or if it needs to remain
RC> backwards compatible with existing code out there.

I think it would affect people, but not code.

People might use the 'process X crashed...' message as part of their
development workflow, to see problems while hacking.

I doubt removing it would affect code. The only thing it's likely to
affect is logging code, and logging code won't care if there's less to
log. The least farfetched idea I can come up with for useful code that
would be affected is if someone clever has built a "supervisor-less"
supervision system based on parsing those messages.

Matthias

Reply | Threaded
Open this post in threaded view
|

An answer: how does SASL know that a process died?

Max Lapshin
Dumping reason of failure to string can take up to 20 GB of memory and many
hours of useless work.

I've seen it many times.

Thus reporting errors must always be done in erlang.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20131031/16fb9b4f/attachment.html>

Reply | Threaded
Open this post in threaded view
|

An answer: how does SASL know that a process died?

Robert Virding-5
In reply to this post by Anthony Ramine-2
No, how the error_handler works is well defined, it is written in erlang, and you can affect what it does. Which are 3 things the sending of messages to error_logger is not. You can also directly SEE what the error_handler does.

Robert

----- Original Message -----

> From: "Anthony Ramine" <n.oxyde>
> To: "Robert Virding" <robert.virding>
> Cc: "Richard Carlsson" <carlsson.richard>, "Erlang Questions" <erlang-questions>
> Sent: Thursday, 31 October, 2013 4:25:47 PM
> Subject: Re: [erlang-questions] An answer: how does SASL know that a process died?
>
> Would you get rid of error_handler too? Because I find that worse than the
> error_logger situation. At least a logger is just a logger, it can?t
> masquerade a function call as another one or do fancy things like this.
>
> --
> Anthony Ramine
>
> Le 31 oct. 2013 ? 16:12, Robert Virding <robert.virding>
> a ?crit :
>
> > What a stupid thing for the system to do! Erlang is Erlang and OTP is
> > something on top of Erlang. It was never written into the spec because we
> > didn't know about it. How can we get rid of it? It is definitely a bug, at
> > best a bad design decision!
>
>

Reply | Threaded
Open this post in threaded view
|

An answer: how does SASL know that a process died?

Richard Carlsson-5
This could be improved by making it work in the same way as undefined
functions etc.: by defining that a particular function in the
error_handler module gets called with the error information as
arguments. Then the formatting and sending to error_logger can be done
in Erlang code, making it much more transparent and easier to change
what it does, and no longer hard-coding a connection in the VM between
process termination and a high level service like the logger. You can
even avoid the whole send operation if you just want to drop these events.

     /Richard

On 2013-11-01 02:46 , Robert Virding wrote:

> No, how the error_handler works is well defined, it is written in erlang, and you can affect what it does. Which are 3 things the sending of messages to error_logger is not. You can also directly SEE what the error_handler does.
>
> Robert
>
> ----- Original Message -----
>> From: "Anthony Ramine" <n.oxyde>
>> To: "Robert Virding" <robert.virding>
>> Cc: "Richard Carlsson" <carlsson.richard>, "Erlang Questions" <erlang-questions>
>> Sent: Thursday, 31 October, 2013 4:25:47 PM
>> Subject: Re: [erlang-questions] An answer: how does SASL know that a process died?
>>
>> Would you get rid of error_handler too? Because I find that worse than the
>> error_logger situation. At least a logger is just a logger, it can?t
>> masquerade a function call as another one or do fancy things like this.
>>
>> --
>> Anthony Ramine
>>
>> Le 31 oct. 2013 ? 16:12, Robert Virding <robert.virding>
>> a ?crit :
>>
>>> What a stupid thing for the system to do! Erlang is Erlang and OTP is
>>> something on top of Erlang. It was never written into the spec because we
>>> didn't know about it. How can we get rid of it? It is definitely a bug, at
>>> best a bad design decision!
>>
>>


Reply | Threaded
Open this post in threaded view
|

An answer: how does SASL know that a process died?

Richard Carlsson-5
In reply to this post by Matthias Lang-2
On 2013-10-31 17:15 , Matthias Lang wrote:

> Hi,
>
> RC> I'm not sure if that can RC be changed or if it needs to remain
> RC> backwards compatible with existing code out there.
>
> I think it would affect people, but not code.
>
> People might use the 'process X crashed...' message as part of their
> development workflow, to see problems while hacking.
>
> I doubt removing it would affect code. The only thing it's likely to
> affect is logging code, and logging code won't care if there's less to
> log. The least farfetched idea I can come up with for useful code that
> would be affected is if someone clever has built a "supervisor-less"
> supervision system based on parsing those messages.

Well, I wasn't going to suggest removing it entirely, but changing the
format so that it's not just a string, and the formatting can be done by
the handler after it decides that it actually cares about this event.
But error loggers would need to handle the new message type.

    /Richard


Reply | Threaded
Open this post in threaded view
|

An answer: how does SASL know that a process died?

Matthias Lang-2
Hi,

ML> >I doubt removing it would...

RC> Well, I wasn't going to suggest removing it entirely, but changing

I want to toss it. It's ugly and useless. But I'm hasty.

I hoping someone would remember why the message-to-error-logger hack
was added in the first place. In the absense of someone who can
remember, I'll just make up some history: it came around the same time
as supervision trees were being invented. People had a hazy idea that
you needed to keep track of processes that went wrong, and the first
idea was to print a message whenever that happened.  Soon after,
someone else came up with the idea of supervisors, but left the
error-logger hack in so as not to step on the inventor's toes.

Matthias

Reply | Threaded
Open this post in threaded view
|

An answer: how does SASL know that a process died?

Robert Virding-5
In reply to this post by Richard Carlsson-5
I think that would be a reasonable solution if we want to keep the functionality. It would make it visible and programmable. And make me happy. :-) Would it need an EEP or could OTP team just fix it.

Robert

----- Original Message -----

> From: "Richard Carlsson" <carlsson.richard>
> To: "Robert Virding" <robert.virding>, "Anthony Ramine" <n.oxyde>
> Cc: "Erlang Questions" <erlang-questions>
> Sent: Friday, 1 November, 2013 10:41:40 AM
> Subject: Re: [erlang-questions] An answer: how does SASL know that a process died?
>
> This could be improved by making it work in the same way as undefined
> functions etc.: by defining that a particular function in the
> error_handler module gets called with the error information as
> arguments. Then the formatting and sending to error_logger can be done
> in Erlang code, making it much more transparent and easier to change
> what it does, and no longer hard-coding a connection in the VM between
> process termination and a high level service like the logger. You can
> even avoid the whole send operation if you just want to drop these events.
>
>      /Richard
>
> On 2013-11-01 02:46 , Robert Virding wrote:
> > No, how the error_handler works is well defined, it is written in erlang,
> > and you can affect what it does. Which are 3 things the sending of
> > messages to error_logger is not. You can also directly SEE what the
> > error_handler does.
> >
> > Robert
> >
> > ----- Original Message -----
> >> From: "Anthony Ramine" <n.oxyde>
> >> To: "Robert Virding" <robert.virding>
> >> Cc: "Richard Carlsson" <carlsson.richard>, "Erlang Questions"
> >> <erlang-questions>
> >> Sent: Thursday, 31 October, 2013 4:25:47 PM
> >> Subject: Re: [erlang-questions] An answer: how does SASL know that a
> >> process died?
> >>
> >> Would you get rid of error_handler too? Because I find that worse than the
> >> error_logger situation. At least a logger is just a logger, it can?t
> >> masquerade a function call as another one or do fancy things like this.
> >>
> >> --
> >> Anthony Ramine
> >>
> >> Le 31 oct. 2013 ? 16:12, Robert Virding
> >> <robert.virding>
> >> a ?crit :
> >>
> >>> What a stupid thing for the system to do! Erlang is Erlang and OTP is
> >>> something on top of Erlang. It was never written into the spec because we
> >>> didn't know about it. How can we get rid of it? It is definitely a bug,
> >>> at
> >>> best a bad design decision!
> >>
> >>
>
>

Reply | Threaded
Open this post in threaded view
|

An answer: how does SASL know that a process died?

Richard Carlsson-5
If it doesn't change the current behaviour (as a first step), I don't
see that it would need an EEP.

    /Richard

On 2013-11-01 12:39 , Robert Virding wrote:

> I think that would be a reasonable solution if we want to keep the functionality. It would make it visible and programmable. And make me happy. :-) Would it need an EEP or could OTP team just fix it.
>
> Robert
>
> ----- Original Message -----
>> From: "Richard Carlsson" <carlsson.richard>
>> To: "Robert Virding" <robert.virding>, "Anthony Ramine" <n.oxyde>
>> Cc: "Erlang Questions" <erlang-questions>
>> Sent: Friday, 1 November, 2013 10:41:40 AM
>> Subject: Re: [erlang-questions] An answer: how does SASL know that a process died?
>>
>> This could be improved by making it work in the same way as undefined
>> functions etc.: by defining that a particular function in the
>> error_handler module gets called with the error information as
>> arguments. Then the formatting and sending to error_logger can be done
>> in Erlang code, making it much more transparent and easier to change
>> what it does, and no longer hard-coding a connection in the VM between
>> process termination and a high level service like the logger. You can
>> even avoid the whole send operation if you just want to drop these events.
>>
>>       /Richard
>>
>> On 2013-11-01 02:46 , Robert Virding wrote:
>>> No, how the error_handler works is well defined, it is written in erlang,
>>> and you can affect what it does. Which are 3 things the sending of
>>> messages to error_logger is not. You can also directly SEE what the
>>> error_handler does.
>>>
>>> Robert
>>>
>>> ----- Original Message -----
>>>> From: "Anthony Ramine" <n.oxyde>
>>>> To: "Robert Virding" <robert.virding>
>>>> Cc: "Richard Carlsson" <carlsson.richard>, "Erlang Questions"
>>>> <erlang-questions>
>>>> Sent: Thursday, 31 October, 2013 4:25:47 PM
>>>> Subject: Re: [erlang-questions] An answer: how does SASL know that a
>>>> process died?
>>>>
>>>> Would you get rid of error_handler too? Because I find that worse than the
>>>> error_logger situation. At least a logger is just a logger, it can?t
>>>> masquerade a function call as another one or do fancy things like this.
>>>>
>>>> --
>>>> Anthony Ramine
>>>>
>>>> Le 31 oct. 2013 ? 16:12, Robert Virding
>>>> <robert.virding>
>>>> a ?crit :
>>>>
>>>>> What a stupid thing for the system to do! Erlang is Erlang and OTP is
>>>>> something on top of Erlang. It was never written into the spec because we
>>>>> didn't know about it. How can we get rid of it? It is definitely a bug,
>>>>> at
>>>>> best a bad design decision!
>>>>
>>>>
>>
>>