Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.
Sign upUnloading Rust-made SOs can lead to segfaults in host program #52138
Comments
This comment has been minimized.
This comment has been minimized.
|
Could we get a backtrace from the segfault? It would also be helpful to have a minimal repository or steps to follow so that we can reproduce this ourselves. Also, the rustc you're using looks somewhat odd -- I would expect something like "rustc 1.27.0 (3eda71b 2018-06-19)" for the first line, is that from a distro or locally built? (Not to say this is the cause, it probably isn't) |
This comment has been minimized.
This comment has been minimized.
|
I am on arch linux x86_64, using rust and hexchat from distro. |
This comment has been minimized.
This comment has been minimized.
|
Are you sure that you have no pointers to code inside the first DLL when unloading? vtables or function tables tends to have dangling reference that are hard to notice. |
This comment has been minimized.
This comment has been minimized.
|
This is a commonly reported issue against |
This comment has been minimized.
This comment has been minimized.
|
I'm not using |
This comment has been minimized.
This comment has been minimized.
|
See #28794 for the OS X equivalent and nagisa/rust_libloading#41 for a report of such an issue occurring on a linux system.
I did not say this is a |
This comment has been minimized.
This comment has been minimized.
|
Oh. Hexchat is single-threaded. This also doesn't happen with a test plugin I made in C. |
This comment has been minimized.
This comment has been minimized.
|
Also note that reloading the same SO over and over never segfaults. I've tested it upwards of 20 times in a row and it didn't segfault. |
This comment has been minimized.
This comment has been minimized.
|
A backtrace would quickly tell what exactly is or is not a problem. Would be great if you obtained one. |
jackcmay
referenced this issue
Sep 23, 2018
Open
Thread safety issue when loading dynamic modules on Linux #1314
This comment has been minimized.
This comment has been minimized.
|
Please keep your thread unsafety issues out of this issue. |
This comment has been minimized.
This comment has been minimized.
|
I'm not sure if I've linked this stack trace anywhere, but:
System information:
|
This comment has been minimized.
This comment has been minimized.
|
it's definitely the linker |
SoniEx2 commentedJul 7, 2018
Steps to reproduce:
libplugin_written_in_rust.so(rust always adds that "lib" prefix for some reason)I don't seem to get the crashes if I have two different plugins under different names.
This is an issue for the
hexchat-plugincrate, and (probably) anything that lets you write plugins in Rust. (rlua? I haven't entirely tested this)(No, this isn't an issue with hexchat's module system. Hexchat's module system is basically just dlopen and dlclose, at least on Linux.)
(No, this shouldn't be dismissed as "unsafe and dangerous"/"unsupported", because if you have heap-allocated globals in your rust code, all you're gonna get is some memory/resource leaks, which aren't considered unsafe. This really shouldn't be segfaulting.)
(Note: this has been a thing for a while, it's not new in 1.27.0.)
Other (important?) things to note: