macOS: panic when using std::thread::current in thread_local Drop implementatiopn

[emilk]

I tried this code:

use std::cell::RefCell;

struct Foo {}

impl Drop for Foo {
    fn drop(&mut self) {
        println!("Dropping Foo");
        println!("Thread: {:?}", std::thread::current().id()); // panics
    }
}

thread_local! {
    static THREAD_LOCAL: RefCell<Option<Foo>> = RefCell::new(None);
}

fn main() {
    THREAD_LOCAL.with(|cell| *cell.borrow_mut() = Some(Foo {}));
    println!("So far so good!");
}

The output of this is:

So far so good!
Dropping Foo
thread '<unnamed>' panicked at 'use of std::thread::current() is not possible after the thread's local data has been destroyed', library/std/src/thread/mod.rs:711:35

Meta

rustc --version --verbose:

rustc 1.72.1 (d5c2e9c34 2023-09-13)
binary: rustc
commit-hash: d5c2e9c342b358556da91d61ed4133f6f50fc0c3
commit-date: 2023-09-13
host: aarch64-apple-darwin
release: 1.72.1
LLVM version: 16.0.5

The same bug is present on nightly:

cargo 1.75.0-nightly (8eb8acbb1 2023-10-17)
release: 1.75.0-nightly
commit-hash: 8eb8acbb116e7923ea2ce33a50109933ed5ab375
commit-date: 2023-10-17
host: aarch64-apple-darwin
libgit2: 1.7.1 (sys:0.18.1 vendored)
libcurl: 7.88.1 (sys:0.4.68+curl-8.4.0 system ssl:(SecureTransport) LibreSSL/3.3.6)
ssl: OpenSSL 1.1.1u  30 May 2023
os: Mac OS 13.4.1 [64-bit]

Backtrace

So far so good!
Dropping Foo
thread '<unnamed>' panicked at 'use of std::thread::current() is not possible after the thread's local data has been destroyed', library/std/src/thread/mod.rs:711:35
stack backtrace:
   0:        0x100f6d72c - std::backtrace_rs::backtrace::libunwind::trace::h65bc41667b946a9b
                               at /rustc/d5c2e9c342b358556da91d61ed4133f6f50fc0c3/library/std/src/../../backtrace/src/backtrace/libunwind.rs:93:5
   1:        0x100f6d72c - std::backtrace_rs::backtrace::trace_unsynchronized::h11e85e00c64d2951
                               at /rustc/d5c2e9c342b358556da91d61ed4133f6f50fc0c3/library/std/src/../../backtrace/src/backtrace/mod.rs:66:5
   2:        0x100f6d72c - std::sys_common::backtrace::_print_fmt::hd30f3b7be3b8d9bb
                               at /rustc/d5c2e9c342b358556da91d61ed4133f6f50fc0c3/library/std/src/sys_common/backtrace.rs:65:5
   3:        0x100f6d72c - <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt::h56d7672c82815b65
                               at /rustc/d5c2e9c342b358556da91d61ed4133f6f50fc0c3/library/std/src/sys_common/backtrace.rs:44:22
   4:        0x100f82578 - core::fmt::rt::Argument::fmt::h6ead82aa10d38e42
                               at /rustc/d5c2e9c342b358556da91d61ed4133f6f50fc0c3/library/core/src/fmt/rt.rs:138:9
   5:        0x100f82578 - core::fmt::write::h632b3cc8e66b4f04
                               at /rustc/d5c2e9c342b358556da91d61ed4133f6f50fc0c3/library/core/src/fmt/mod.rs:1094:21
   6:        0x100f6b7bc - std::io::Write::write_fmt::hc28441b249a4971d
                               at /rustc/d5c2e9c342b358556da91d61ed4133f6f50fc0c3/library/std/src/io/mod.rs:1714:15
   7:        0x100f6d584 - std::sys_common::backtrace::_print::h0d2f8b8a08c5cc48
                               at /rustc/d5c2e9c342b358556da91d61ed4133f6f50fc0c3/library/std/src/sys_common/backtrace.rs:47:5
   8:        0x100f6d584 - std::sys_common::backtrace::print::h8057ced4b0f9fdc1
                               at /rustc/d5c2e9c342b358556da91d61ed4133f6f50fc0c3/library/std/src/sys_common/backtrace.rs:34:9
   9:        0x100f6e7a0 - std::panicking::default_hook::{{closure}}::h8157fa8f0f7934b5
                               at /rustc/d5c2e9c342b358556da91d61ed4133f6f50fc0c3/library/std/src/panicking.rs:269:22
  10:        0x100f6e530 - std::panicking::default_hook::hdaefe3bfb5fe212c
                               at /rustc/d5c2e9c342b358556da91d61ed4133f6f50fc0c3/library/std/src/panicking.rs:288:9
  11:        0x100f6ecd0 - std::panicking::rust_panic_with_hook::h21091a3c79c5da9c
                               at /rustc/d5c2e9c342b358556da91d61ed4133f6f50fc0c3/library/std/src/panicking.rs:705:13
  12:        0x100f6ebdc - std::panicking::begin_panic_handler::{{closure}}::hd2f65b958d3068b8
                               at /rustc/d5c2e9c342b358556da91d61ed4133f6f50fc0c3/library/std/src/panicking.rs:597:13
  13:        0x100f6db0c - std::sys_common::backtrace::__rust_end_short_backtrace::h53ec33e49ec66621
                               at /rustc/d5c2e9c342b358556da91d61ed4133f6f50fc0c3/library/std/src/sys_common/backtrace.rs:151:18
  14:        0x100f6e948 - rust_begin_unwind
                               at /rustc/d5c2e9c342b358556da91d61ed4133f6f50fc0c3/library/std/src/panicking.rs:593:5
  15:        0x100f88ff0 - core::panicking::panic_fmt::h3bbf9265d206434c
                               at /rustc/d5c2e9c342b358556da91d61ed4133f6f50fc0c3/library/core/src/panicking.rs:67:14
  16:        0x100f88fbc - core::panicking::panic_display::ha9c9b958d809a439
                               at /rustc/d5c2e9c342b358556da91d61ed4133f6f50fc0c3/library/core/src/panicking.rs:150:5
  17:        0x100f88fbc - core::panicking::panic_str::h7a35ddea936ddc80
                               at /rustc/d5c2e9c342b358556da91d61ed4133f6f50fc0c3/library/core/src/panicking.rs:134:5
  18:        0x100f88fbc - core::option::expect_failed::h0a4ede9c7736875e
                               at /rustc/d5c2e9c342b358556da91d61ed4133f6f50fc0c3/library/core/src/option.rs:1952:5
  19:        0x100f6999c - core::option::Option<T>::expect::h8cc8fc4b662f0246
                               at /rustc/d5c2e9c342b358556da91d61ed4133f6f50fc0c3/library/core/src/option.rs:898:21
  20:        0x100f6999c - std::thread::current::h1ab3d52925760f1c
                               at /rustc/d5c2e9c342b358556da91d61ed4133f6f50fc0c3/library/std/src/thread/mod.rs:711:35

Operating system

This seems to only affect macOS. I've tested it on macOS Venture 13.4.1.

On Linux everything works as expected.

Why is this important?

I discovered this problem because I am using crossbeam::channel in a Drop implementation to communicate to another thread, and crossbeam calls std::thread::current.

It seems very reasonable to me that std::thread::current should always work. In particular, it is very useful to be able to have a thread-local object deregister itself on destroy by e.g. removing its thread-id from a global set of active threads, or sending it over a channel to a parent thread.

Workarounds

None that I have found (yet)

[joboet]

See #110708 for more context. It's probably impossible to make thread::current work after main on all platforms, since it uses a TLS variable with a destructor itself, and the run-order of TLS variables is not guaranteed.

[Noratrieb]

Closing as this doesn't seem to be a bug.