Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
in native code, make Printexc.get_callstack work in new threads #1895
One would expect this code to behave the same regardless of whether THREAD is set:
But the observed behavior is:
ie in the new thread, the callstack is one frame.
This is because caml_top_of_stack is NULL in new threads, presumably resulting Printexc.get_callstack stopping after the first (unconditional) frame. caml_top_of_stack is NULL because the th->top_of_stack for new thread starts as NULL and is initialized to a proper value too late (after caml_leave_blocking_section, which does caml_top_of_stack = th->top_of_stack). So the fix is to initialize to a proper value before the call to caml_leave_blocking_section.
With this pull request, the observed behavior is:
xavierleroy left a comment
The handling of stack-related global variables is a bit of a mess, and it took me a while to understand what's going on. Clearly, the current code is not good and the proposed fix is much better.
I hope but am not sure this is enough to get 100% reliable backtraces in the presence of threads.
Another review by another core developer would be welcome, in case I missed something.
This test fails on the flambda-enabled CI machine:
@gasche Flambda and classic deals with externals slightly differently. One solution would be to not associate any location to the code that wraps an external into an OCaml function, though that's not really a good option. The test is failing, but this behavior is fine for me.
Jul 12, 2018