-
Notifications
You must be signed in to change notification settings - Fork 246
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
gimli/libbacktrace don't handle dynamically loaded libraries #238
Comments
Could this explain backtraces in dynamically loaded libraries becoming |
I don't believe this is related to gimli because gimli isn't used in libstd. That being said that still sounds like a regression that's likely related to this crate! (just separate) |
Thanks, I've filed a separate issue at rust-lang/rust#67599. |
Assuming this is still a problem, would calling |
At least on 0.36:
I'll put up a PR for adding the ability to reload the library cache shortly. @alexcrichton do you have a preference for rolling it into the existing |
Given that |
I think this is a better solution that requiring users to call a function to clear the cache. |
Currently iteration over all dynamic objects happens once in libbacktrace/gimli (gimli for sure, libbacktrace is a best approximation). This means that if a backtrace is generated and then afterwards a dynamic object is loaded (e.g. via
dlopen
) the backtraces through that new dynamic object may be missing symbol information. We'll likely need to add a fallback in gimli where if a symbol doesn't hit the cache of libraries we know about we check again to see if any new libraries have been opened.The text was updated successfully, but these errors were encountered: