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

Robert Virding robert.virding@REDACTED
Thu Oct 31 16:12:17 CET 2013


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@REDACTED>
> 
> 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@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