Skip to content
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

Open
alexcrichton opened this issue Aug 8, 2019 · 7 comments
Open

gimli/libbacktrace don't handle dynamically loaded libraries #238

alexcrichton opened this issue Aug 8, 2019 · 7 comments
Labels
bug gimli Related to the gimli implementation

Comments

@alexcrichton
Copy link
Member

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.

@t-mw
Copy link

t-mw commented Oct 30, 2019

Could this explain backtraces in dynamically loaded libraries becoming <unknown> from Rust 1.37 onwards? I also saw that rust-lang/rust#57967 was causing a similar issue in >= 1.37 (rust-lang/rust#61416), but that appears to have been fixed.

@alexcrichton
Copy link
Member Author

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)

@t-mw
Copy link

t-mw commented Dec 27, 2019

Thanks, I've filed a separate issue at rust-lang/rust#67599.

@alexcrichton alexcrichton added the gimli Related to the gimli implementation label May 8, 2020
@itamarst
Copy link

Assuming this is still a problem, would calling backtrace::clear_symbol_cache() after every dlopen() be an effective workaround?

@jmrgibson
Copy link

jmrgibson commented Jun 7, 2022

At least on 0.36:

  1. this is still a problem
  2. calling clear_symbol_cache() doesn't clear cache.libraries, only cache.mappings. So if you load a new library, you won't get any new symbols.

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 clear_symbol_cache function? or a new function (e.g. reload_native_library_cache)

@jmrgibson
Copy link

Given that cache.mappings has indexes into cache.libraries, I think I'll make a new function that clears both cache.libraries AND cache.mappings.

@bjorn3
Copy link
Member

bjorn3 commented Jun 9, 2022

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.

I think this is a better solution that requiring users to call a function to clear the cache.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug gimli Related to the gimli implementation
Projects
None yet
Development

No branches or pull requests

6 participants