-
Notifications
You must be signed in to change notification settings - Fork 12.1k
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
Calling HashMap::new() from Dynamically loaded lib, causes Segfault, Illegal Instruction #18521
Comments
Looks like the runtime isn't getting initialized properly. The segfault is occurring after the plugin panics due to an error in the task local RNG:
|
Thanks for looking at this. That call stack clearly shows it is choking in the rng function, which is more than I was able to deduce. Can I ask how you generated that call stack/backtrace? The best I was able to do was step through the code in my IDE (with gdb backend), even though I was using rust libs compiled with debug symbols, it would just step straight from HashMap::new() to the exception in rust_try(), with no steps in between. To the issue at hand, I may be in way over my head, but how is creating a HashMap inside the plugin different than creating it in the main application? Why is the runtime in a different state (not initialized properly) in the plugin, should it not be in the same state as the calling code? |
I inserted a breakpoint in GDB at the I have no idea why it's breaking. Compiler plugins are loaded in the same way, and they can use hashmaps without any problems. It might be that there's some thing that blows up if it doesn't happen in the main binary the first time? |
Ok, I've managed to debug it a bit further with some manual GDB commands. Here is the crude gdb output:
|
Interesting! Here's a smaller version of plugin.rs that causes the same issue: use std::io::fs::File;
#[no_mangle]
pub fn init()
{
let _ = File::open(&Path::new("/dev/urandom")).unwrap();
} |
Does it fail with other files? |
@huonw yep |
Ok, maybe need to rename the title of this issue, its got nothing to do with HashMap now. |
Are you building the main program with -C prefer-dynamic? Otherwise you're going to have libplugin.so linking libstd dynamically and main linking it statically, and weird things are going to happen after dlopen |
Oh, right! |
Ohh. Thanks! I was incorrectly assuming that rustc uses dynamic libs automatically. No wonder my compiled file sizes were bigger than I expected. Thanks again guys! |
I was running across this issue in my project last week.
See Stackoverflow question here and reddit.com/r/rust thread here
Basically, calling HashMap::new() inside my runtime-dynamically-loaded plugin lib is causing an unwind, and then rust segfaults while doing the unwind. Running the application on the command line gives
Illegal Instruction
output, running inside gdb gives:I've produced a minimal test case:
main.rs
plugin.rs
Changing HashMap to TreeMap in plugin.rs causes the segfault to go away, and the program runs correctly.
Im using the latest Rust master codebase, compiled on linux x64.
The text was updated successfully, but these errors were encountered: