You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
To trigger the crash: close the window with CTRL + W.
The app uses egui and tracing-appender and the combination somehow triggers an AccessError (cannot access a Thread Local Storage value during or after destruction: AccessError) that eventually is caused by a function get_slow in thread_local:
Not sure if I'm on the right track here. But since the documentation on this crate does not seem to suggest that ThreadLocal::get can panic in certain situations, and it seems it can actually panic in this case it seems this is a bug.
The text was updated successfully, but these errors were encountered:
(panic stuff)
7: std::thread::local::LocalKey<T>::try_with
at /rustc/0d8b3346a3992ab11ea35ff0fb95a6864b91f797/library/std/src/thread/local.rs:286:12
8: std::thread::local::LocalKey<T>::with
at /rustc/0d8b3346a3992ab11ea35ff0fb95a6864b91f797/library/std/src/thread/local.rs:262:9
9: thread_local::thread_id::get
at /home/meowjesty/.cargo/registry/src/index.crates.io-6f17d22bba15001f/thread_local-1.1.8/src/thread_id.rs:155:13
10: thread_local::ThreadLocal<T>::get
at /home/meowjesty/.cargo/registry/src/index.crates.io-6f17d22bba15001f/thread_local-1.1.8/src/lib.rs:185:24
(some more tracing stuff)
17: tracing::span::Span::new_with
at /home/meowjesty/.cargo/registry/src/index.crates.io-6f17d22bba15001f/tracing-0.1.40/src/span.rs:448:9
18: tracing::span::Span::new::{{closure}}
at /home/meowjesty/.cargo/registry/src/index.crates.io-6f17d22bba15001f/tracing-0.1.40/src/span.rs:437:44
19: tracing_core::dispatcher::get_default
at /home/meowjesty/.cargo/registry/src/index.crates.io-6f17d22bba15001f/tracing-core-0.1.32/src/dispatcher.rs:391:16
20: tracing::span::Span::new
at /home/meowjesty/.cargo/registry/src/index.crates.io-6f17d22bba15001f/tracing-0.1.40/src/span.rs:437:9
21: mirrord_layer::socket::ops::fcntl
at /home/meowjesty/dev/metalbear/mirrord/mirrord/layer/src/socket/ops.rs:786:1
22: mirrord_layer::socket::hooks::fcntl_detour
at /home/meowjesty/dev/metalbear/mirrord/mirrord/layer/src/socket/hooks.rs:198:15
23: <unknown>
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
fatal runtime error: failed to initiate panic, error 5
It's an edge case, but perhaps need to change .with to try_with?
I'm trying to get to the bottom of a weird crash I'm getting. I have minimal reproducible here:
https://github.com/gerwin3/thread-local-accesserror-repro/blob/main/src/main.rs
System:
To trigger the crash: close the window with CTRL + W.
The app uses
egui
andtracing-appender
and the combination somehow triggers anAccessError
(cannot access a Thread Local Storage value during or after destruction: AccessError) that eventually is caused by a functionget_slow
inthread_local
:thread_local-rs/src/thread_id.rs
Line 169 in 6920311
My guess is that calling
with
on a thread local may not always be correct if the caller is running a destructor (?) in any case the docs ofLocalKey::with
seem to suggest so: https://doc.rust-lang.org/std/thread/struct.LocalKey.html#method.withNot sure if I'm on the right track here. But since the documentation on this crate does not seem to suggest that
ThreadLocal::get
can panic in certain situations, and it seems it can actually panic in this case it seems this is a bug.The text was updated successfully, but these errors were encountered: