-
Notifications
You must be signed in to change notification settings - Fork 13.3k
Backtrace rendering inconsistent between std::backtrace
and panics
#71706
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
Comments
Indeed looks like the we have two backtrace formatters: Both use the I have no idea why this is duplicated (other than maybe "historic accident"). |
@alexcrichton do you have any idea why backtraces are formatted inconsistently between panics and |
Hm I'm not sure why this is inconsistent. It looks like it's all using the same things internally, but I don't have a Linux machine right now to test with unfortunately. |
The panic version doesn't require capturing and resolving all frames in advance. This is faster and would be essential for displaying a backtrace in case of OOM or stackoverflow if we want to do thzt in the future because it requires much less memory. |
I'm not really familiar with this code yet, but I think the difference in formatting is because our panic backtrace formatter constructs a new I think we can reasonably share some more code between these formatters if we'd like to make formatting and filtering more consistent between them. |
The following code (a trimmed version of the original version):
compiled using:
produces no warnings or errors. Then run with RUST_BACKTRACE=1 produces:
Which seems have the same differences as the original issue but with more/less items order reversed? |
I tried this code on nightly:
This prints:
As you can see, the first backtrace omits the frame number for some functions, probably because these all share a single frame after inlining. The panic backtrace for some reason lacks this information.
Looks like we have two separate pieces of backtrace-printing code in libstd, and they behave differently?
The text was updated successfully, but these errors were encountered: