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

Panic due to double SymInitializeW #37

Open
branpk opened this issue Jun 8, 2021 · 1 comment
Open

Panic due to double SymInitializeW #37

branpk opened this issue Jun 8, 2021 · 1 comment

Comments

@branpk
Copy link

branpk commented Jun 8, 2021

Rust on Windows has to call SymInitializeW before generating a backtrace, and it doesn't call SymCleanup afterward. If AddressInfoObtainer is then used, it calls SymInitializeW again, which fails because it has already been called.

Example code (set RUSTBACKTRACE=1):

use std::panic::catch_unwind;
use dlopen::raw::{AddressInfoObtainer, Library};

fn main() {
    let library = Library::open("example.dll").unwrap();
    let pointer: *const () = unsafe { library.symbol("foo") }.unwrap();

    catch_unwind(|| panic!()); // this generates a backtrace. Backtrace::capture() probably works too

    // Panics because SymInitializeW returns an error
    AddressInfoObtainer::new().obtain(pointer).unwrap();
}

There is some background on how the backtrace crate handled a similar conflict here (also explains why Rust doesn't call SymCleanup).

I think dlopen should:

  • Call SymInitializeW but ignore its return value
  • Never call SymCleanup

This behavior is awkward, but I think it's the only way to be compatible with how Rust uses SymInitializeW.

I can submit a PR for this if it's welcome.

@OpenByteDev
Copy link

I implemented this in my fork dlopen2

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

No branches or pull requests

2 participants