[erlang-questions] error_logger events sent by emulator

[Loïc Hoguin]

Hey, thanks for the pointers.

On 04/28/2014 12:03 AM, Matthias Lang wrote:
> I think the earlier discussion you remember starts here (my mail):
>
>    http://erlang.org/pipermail/erlang-questions/2013-October/075867.html
>
> My biased summary of the thread:
>
>    - Everyone agreed the behaviour was unfortunate/nobody was a fan of it.
>
>    - I thought it was so pointless that it might be possible to ditch
>      the emulator code entirely, i.e. just don't report those errors.
>      Others thought that might be a bad idea, though nobody gave a
>      concrete example which showed why.

After a little thinking I got to this point:

I'm OK with the C code sending these errors. There are a lot of other 
errors sent by the emulator, and it doesn't seem like all of them could 
be moved to the Erlang side anyway. So the VM has to know where to send 
errors. It's very useful for newcomers too, start the shell, spawn a 
process, it crashes, you get an error printed. Under no circumstances 
should this feedback ever be removed (at least not by default).

I'm not OK with how this particular error is sent. What the code 
basically does is:

  *  Detect process crash
  *  Extract stacktrace etc. as Erlang terms
  *  Format Erlang terms as short string
  *  Send string to error_logger

Note that the stacktrace may contain arguments depending on how the 
process crashed. Also note that if the error isn't catched there is two 
string formattings going on as the error received is {emulator, "~s~n", 
Msg} and this results in another formatting call when printing it.

What I would like to happen:

  *  Detect process crash
  *  Extract stacktrace etc. as Erlang terms
  *  Make sure the stacktrace contains no arguments, only arity
  *  Make sure the stacktrace is below a certain size (for example last 
5 calls by default, perhaps configurable through process flags)
  *  Send error as Erlang term to error_logger

The error received would be similar to {emulator, "Error in process ~p 
on node ~p with exit value: ~p~n", [Pid, Node, Stacktrace]} which makes 
it easy to extract information or format as desired. Basically the same 
as what we get now, except pre-formatting.

Not sending arguments and limiting the stacktrace also ensures that we 
don't flood the VM needlessly. In fact it's potentially better than what 
we have today because we might not need to create an Erlang term for the 
whole stacktrace and then print a short portion of it when formatting, 
we can just take the last N calls. If the stacktrace is huge, we 
potentially save a lot of resources.

I don't see it being backward incompatible as I'm probably the only 
crazy person who went ahead and parsed that awful string to extract 
information.

> I ended up dealing with the problem by avoiding it---I wrapped spawn()
> so that the errors I was seeing never made it to that emulator code.
> proc_lib:spawn() does the same thing. But it looks like your problem
> is more general than mine was.

Well I could solve it exactly the way you did to be perfectly honest. I 
didn't think of that, so I ended up parsing the string for the info I 
needed (and so far it works OK). But I feel it'd be better with a proper 
OTP patch. I'm willing to write said patch if that seems interesting to 
others.

So yeah, if any of what I just wrote makes sense to you, please tell me 
and I'll do a first try at a patch.

-- 
Loïc Hoguin
http://ninenines.eu