[erlang-questions] Truncated error reports

[Björn-Egil Dahlberg]

There is a currently a Pull Request that deals with this:
https://github.com/erlang/otp/pull/359

I believe that PR will make into master in one form or another.

Why is the error truncated in the first place? If I had to guess, and sadly
I have to, I think it has to do with memory and copying.

When a process terminates with an error, it could potentially have a very
large message (state and stacktrace) which is then sent to the error logger.
Currently, before the error message is sent by the dying process it will
truncate the message to 200 (default) characters. This means  we have less
to copy and we are less likely to kill the system, i.e. we have more
control.
So, if not truncated it could in the worst case kill the system. See my
last entry in the PR for an example.

I think the heart of the matter is that we have less control when a process
dies and thus have no control over what the error message is or  more
importantly how large it is. So we truncate it to have some control.
The problem is compounded by the lack of sharing of terms.

Aside: In this particular case of error message propagation it should be
possible to just give the heap of the dying process as a heap fragment to
the receiving process. The dying process should't need it anyway. No copy
should be needed.

// Björn-Egil


2014-10-25 0:41 GMT+02:00 Ransom Richardson <ransomr@REDACTED>:

>  I've been trying to get useful information (the full stack) from Cowboy
> error reports. But all of our reports are truncated. I found this
> http://stackoverflow.com/questions/17596686/truncated-error-report-in-erlang​,
> but the solution didn't work for me.
>
>
>  I looked at the emulator source code and found the undocumented +#
> switch which controls precision. Using this switch, I verified that the
> errors are being truncated by the emulator itself (see below).
>
>
>  Is this truncation intentional or a bug? Is there a better way around it
> than the +# switch?
>
>
>  At a higher level, is there a better way to get error/crash information
> from a process than going through error_logger? We're using lager and
> erlbrake and both add error_logger handlers that parse the text error
> reports. I would much rather deal with the reason term directly. Is there a
> way to be notified of process termination other than error_logger?
>
> ​
>
>
>
>  talko@REDACTED:~/talko_service/erl/session$ erl
> Erlang/OTP 17 [erts-6.1.2] [source] [64-bit] [smp:6:6] [async-threads:10]
> [hipe] [kernel-poll:false]
>
>  Eshell V6.1.2  (abort with ^G)
> 1> spawn(fun() -> erlang:error([$x || _ <- lists:seq(0,5000)]) end).
> <0.35.0>
>
>  =ERROR REPORT==== 24-Oct-2014::22:23:21 ===
> Error in process <0.35.0> with exit value:
> {"xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx...
>
>
>  talko@REDACTED:~/talko_service/erl/session$ erl +#10
> Erlang/OTP 17 [erts-6.1.2] [source] [64-bit] [smp:6:6] [async-threads:10]
> [hipe] [kernel-poll:false]
>
>  Eshell V6.1.2  (abort with ^G)
> 1> spawn(fun() -> erlang:error([$x || _ <- lists:seq(0,5000)]) end).
> <0.35.0>
> 2>
> =ERROR REPORT==== 24-Oct-2014::22:23:34 ===
> Error in process <0.35.0> with exit value: {"xxxxxxxx...
>
>
>  talko@REDACTED:~/talko_service/erl/session$ erl +#400
>  Erlang/OTP 17 [erts-6.1.2] [source] [64-bit] [smp:6:6]
> [async-threads:10] [hipe] [kernel-poll:false]
>
>  Eshell V6.1.2  (abort with ^G)
> 1> spawn(fun() -> erlang:error([$x || _ <- lists:seq(0,5000)]) end).
> <0.35.0>
> 2>
> =ERROR REPORT==== 24-Oct-2014::22:23:49 ===
> Error in process <0.35.0> with exit value:
> {"xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx...
>
>
>
>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20141025/73c70c72/attachment.htm>