Panic due to destroyed TLS value #145
Description
I was running a multithreaded program with lots of logging statements under GDB, and I got the following panic due to a log statement coming from inside a Drop implementation. (The drop calls were invoked due to crossbeam's epoch-based GC)
panicked at 'cannot access a TLS value during or after it is destroyed: AccessError'
10: core::result::unwrap_failed
at src/libcore/result.rs:1084
11: core::result::Result<T,E>::expect
at /rustc/f7af19c279b8b7ea3d2c21fcbd67164af8d5d968/src/libcore/result.rs:879
12: std::thread::local::LocalKey<T>::with
at /rustc/f7af19c279b8b7ea3d2c21fcbd67164af8d5d968/src/libstd/thread/local.rs:239
13: <env_logger::Logger as log::Log>::log
at /home/david/.cargo/registry/src/github.com-1ecc6299db9ec823/env_logger-0.7.0/src/lib.rs:810
14: log::__private_api_log
at /home/david/.cargo/registry/src/github.com-1ecc6299db9ec823/log-0.4.8/src/lib.rs:1393
...
32: __call_tls_dtors
33: start_thread
34: __clone
I think the call of std::thread::LocalKey::with should be replaced with try_with, and in the event of it returning an AccessError, (meaning the TLS key has already been destroyed) a new Formatter should be allocated on the stack, as in the other exceptional code paths.