stacktrace regression

[leoliu]

After upgrading to git master i.e. with the OTP 21 fix. I have noticed that Yaws stops providing useful stacktrace. For example here is what the new stacktrace looks like:

ERROR erlang code threw an uncaught exception:
 File: appmod:0
Class: error
Exception: {badmatch,{error,enoent}}
Req: {http_request,'POST',{abs_path,"/media/upload"},{1,1}}
Stack: [{yaws_server,deliver_dyn_part,8,
                     [{file,"yaws_server.erl"},{line,2886}]},
        {yaws_server,aloop,4,[{file,"yaws_server.erl"},{line,1251}]},
        {yaws_server,acceptor0,2,[{file,"yaws_server.erl"},{line,1074}]},
        {proc_lib,init_p_do_apply,3,[{file,"proc_lib.erl"},{line,247}]}]

and is the same for any exception. I think the reason is after the otp21 fix stacktrace is retrieved from a new try ... catch which overrides the real one.

[leoliu]

OTP's rebar3 project introduces a macro that might be of use.

https://github.com/erlang/rebar3/commit/5f9b4293bc029e2132d7c442cb5b4480915ea0e4

-ifdef(fun_stacktrace).
-define(WITH_STACKTRACE(T, R, S), T:R -> S = erlang:get_stacktrace(),).
-else.
-define(WITH_STACKTRACE(T, R, S), T:R:S ->).
-endif.

[vinoski]

Yaws already uses a similar macro, MAKE_ST.

This issue is isolated to a particular spot in yaws_server.erl where it's already handling an exception but gets the stack trace incorrectly because it's not using MAKE_ST.

[leoliu]

Thanks for the prompt fix.

is ?stack safe to use in yaws_server:handle_out_reply/5 line 3401?

[vinoski]

Safe? Yes. Effective? No.

I wasn't quite sure how to fix that one, so I left it as is for now so I could make the fix for this issue as quickly as possible. I'll revisit that one in the future.

[leoliu]

Sounds like a good plan. Thanks for the answer.