Better backtrace cleaning on panic #40201
Comments
|
I don't think we should too aggressively try to clean backtraces because we run the risk of hiding actually useful information. I'd be against capturing a backtrace at the beginning of tests/main/etc as that's somewhat surprising and we should otherwise be able to infer the bottom of the stack. I'd be fine just adding more heuristics. |
|
What do you mean by surprising? |
|
It's a pretty weighty piece of code to unconditionally run, it's also quite slow. We should avoid running it by default. |
|
Not wrong |
|
@Yamakaky |
|
No, that's what I meant. |
Yamakaky
added a commit
to Yamakaky/rust
that referenced
this issue
Mar 4, 2017
Correctly handles panics in threads and tests. First, the frames after `__rust_maybe_catch_panic` are discarded, then it uses a blacklist that does some more fine-tuning. Since frames after the call to `__rust_maybe_catch_panic` seem to be platform-independant, `BAD_PREFIXES_BOTTOM` could probably be cleaned a bit. Fixes rust-lang#40201
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Followup of #38165.
The current behaviour is to maintain a blacklist of frames to remove from the backtrace. This poses problems in portability and accuracy. For example, the bottom of the backtrace is not cleaned when the panic is in a test or an other thread.
I propose that just before calling the user main/test/closure, the calling code would capture a backtrace. Then, on panic, the frames present is the backtrace pre and post panic would be removed. That way, no need to have a big whitelist. Some small post-processing may be needed to remove some additional frames.
A few questions:
__rust_maybe_catch_panicused on all the platforms? If so, it could be used as a basis for this technique, since it's used for tests, the main thread and the secondary threads.The text was updated successfully, but these errors were encountered: