[erlang-questions] error_logger events sent by emulator

[Loïc Hoguin]

Me again.

Putting aside how it's sent by the C code, and seeing as I need to 
handle the messages coming from the emulator for my purposes, I hit an 
issue.

The emulator's error events are sent as a *string*. Not only a string, 
but a string which, to my knowledge, can't be parsed with anything that 
comes with OTP. In particular I need to figure out the number of 
arguments of the last call in the stacktrace, and when it comes as a 
list of arguments I get things like this:

     "[<<17 bytes>>,#Fun<cowboy_http.19.115752622>]"

If you have tips on how to get 2 from that format, please enlighten me. 
Note that it should work not only in this case but also any other cases 
including if it had arguments as lists or tuples.

Not only is it hard to programmatically figure out what's going on, but 
it's also inconsistent with all the other error reports that 
error_logger handlers receive.

Can anything be done about this, and how can I help? I'm willing to send 
a patch to get proper Erlang terms instead of a string, but this is 
happening in the C code so I'll need some directions.

Thanks.

On 04/20/2014 11:51 PM, Loïc Hoguin wrote:
> Hello,
>
> I am playing with error_logger handlers at the moment. I notice that I
> receive events like this one:
>
> {error, <0.68.0>, {emulator,"~s~n",
>                           ["Error in process <0.649.0> on node
> 'ct@REDACTED' with exit value:
> {[{reason,function_clause},{mfa,{rest_resource_etags,generate_etag,2}},{stacktrace,[{cowboy_http,quoted_string,[<<17
> bytes>>,#Fun<cowboy_http.19.115752622>],[{file,\"src/cowboy_http.erl\"},{line,653}]},{cowboy_http,nonempty_list,2,[{file,\"src/cowboy_http.erl\"},{...
> \n"]}}
>
> I remember reading about these from a previous discussion but I can't
> find it right now. If I recall they are messages sent directly from the
> C code, and again if I recall there was suggestions about removing this
> type of error entirely and/or replacing with Erlang code instead of
> making the C code aware of the error_logger.
>
> Is there any plans to change this in the future? If not, can you provide
> details on what exactly triggers these sort of events? It's hard to
> decide what events to ignore without knowing that.
>
> Thanks!
>

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