[erlang-questions] Trunkated stacktrace

[Tomas Abrahamsson]

On Tue, Nov 1, 2016 at 7:15 PM, Robert Raschke <rtrlists@REDACTED>
wrote:

> Personally, I interpret deep stacktraces to be a result of frameworkitis
> or poorly factored code, as something to avoid or fix. But that's probably
> an unpopular opinion to have these days.
>
I've been bitten by truncated stacktraces a few times in code recursing
over data structures, for instance traversing some data type descriptions
or in parse transforms. Granted, this may not be everyday tasks, but
debugging becomes so much more difficult with truncation. So if there is no
drawback, I'd welcome upping the default. So far, I've never found I that I
wanted to see fewer levels of stack when debugging.

BRs
Tomas


> On 1 Nov 2016 17:09, "Vans S" <vans_163@REDACTED> wrote:
>
>> Increase the stack trace depth. 8 is default.  No serious drawbacks I can
>> think of. Indeed 8 is often too little.
>>
>>
>> On Tuesday, November 1, 2016 11:25 AM, Håkan Mattsson <hm@REDACTED>
>> wrote:
>>
>>
>>
>> Hi,
>>
>> Anybody who knows why the stacktrace returned by process_info(Pid,
>> current_stacktrace) is truncated to 8 items? Is it due to some performance
>> consideration?
>>
>>
>> In order to get more usable stacktraces I were thinking of doing this
>> little fix in our system? Do you foresee any drawbacks with it?
>>
>> Btw, 8 happens to be the default of the system flag backtrace_depth.
>>
>>
>> diff --git a/otp/erts/emulator/beam/erl_bif_info.c
>> b/otp/erts/emulator/beam/erl_bif_info.c
>> index d7f1e2d..2dc310f 100755
>> --- a/otp/erts/emulator/beam/erl_bif_info.c
>> +++ b/otp/erts/emulator/beam/erl_bif_info.c
>> @@ -1607,7 +1607,7 @@ current_stacktrace(Process* p, Process* rp, Eterm**
>> hpp)
>>      Eterm mfa;
>>      Eterm res = NIL;
>>
>> -    depth = 8;
>> +    depth = erts_backtrace_depth;
>>      sz = offsetof(struct StackTrace, trace) + sizeof(BeamInstr *)*depth;
>>      s = (struct StackTrace *) erts_alloc(ERTS_ALC_T_TMP, sz);
>>      s->depth = 0;
>>
>>
>> /Håkan
>>
>>
>> _______________________________________________
>> 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
>>
>
> _______________________________________________
> 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/20161101/828babfc/attachment.htm>