Stack overflow when tls_callback called on x86_64-pc-windows-gnu
#140798
Comments
rustbot
added
the
needs-triage
This comment has been minimized.
This comment has been minimized.
rustbot
added
E-needs-mcve
|
The code for the dll is this one: https://github.com/nagisa/rust_libloading/blob/master/src/test_helpers.rs Compile it with Then write some code to load and unload it: fn main() {
let join_handles: Vec<_> = (0..16)
.map(|_| {
std::thread::spawn(|| unsafe {
for _ in 0..10000 {
// Use libloading, or write LoadLibrary & FreeLibrary yourself.
let lib = Library::new("libtest_helpers.module").expect("open library");
let _: Symbol<unsafe extern "C" fn(u32) -> u32> =
lib.get(b"test_identity_u32").expect("get fn");
lib.close().expect("close is successful");
}
})
})
.collect();
for handle in join_handles {
handle.join().expect("thread should succeed");
}
}This issue doesn't always trigger. I have found that, debug it with |
rustbot
added
the
T-libs
This comment has been minimized.
This comment has been minimized.
rustbot
added
the
E-needs-bisection
Maybe #127912 , I guess. |
|
Looking at the stack trace, we panic here rust/library/std/src/sys/thread_local/key/windows.rs Lines 114 to 115 in e964cca and then when trying to check whether we're panicking while inside another panic and we need to abort, we hit the same code path rust/library/std/src/panicking.rs Line 433 in e964cca It seems that the issue can occur in more than just windows-gnu, but windows-gnu simply more likely to exhaust tls indices than others (somehow.. I'm not entirely clear on this part) cc @joboet @rustbot label: -E-needs-mcve -E-needs-bisection +S-has-bisection -needs-triage +A-thread-locals +A-panic |
rustbot
added
A-panic
|
You're right. I asked the question about |
|
This is a duplicate of #136120 but the failure mode is more interesting here, since seemingly nothing in the library is using TLS – were it not for a particularity of Windows: As it doesn't support specifying destructors for TLS keys, the rust/library/std/src/sys/thread_local/guard/windows.rs Lines 81 to 92 in ac9ac0e Still, since there aren't any user-defined thread locals, that callback wouldn't be a problem, were it not for the Lines 119 to 126 in ac9ac0e This function's job is to destroy the local rust/library/std/src/thread/current.rs Lines 266 to 274 in ac9ac0e Unfortunately, the current implementation always initialises that key upon use, which necessitates allocating a new TLS key. rust/library/std/src/sys/thread_local/os.rs Lines 167 to 169 in ac9ac0e TLS keys are a limited resource, so they'll eventually run out, leading to a panic. The panic handler also uses TLS and will thus run into the same situation, leading to infinite recursion and the stack overflow described here. As @rustbot claim |
That sounds a little wierd because the DLL doesn't contain TLS variables.
You see, |
Recently the CI of
libloadingcould not pass. I tested it and found this issue. It only occurs on*-gnutarget, not*-msvcor*-gnullvmtarget. I have noticed that*-msvcand*-gnullvmhas native thread local support, but*-gnudoes not. Is it the cause?Meta
rustc --version --verbose:Backtrace
The text was updated successfully, but these errors were encountered: