dtor - broken by upgrading tokio from 1.38.0 to 1.39.1 - use of std::thread::current() is not possible after the thread's local data has been destroyed

[Tockra]

Hello,

in the past I used dtor in combination with tokio to clean up my test environment after the test execution.
Everything worked fine.

But after I removed my Cargo.lock and recreated it, I received alway following message :

thread '<unnamed>' panicked at library/std/src/thread/mod.rs:741:19:
use of std::thread::current() is not possible after the thread's local data has been destroyed
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
fatal runtime error: failed to initiate panic, error 5
error: test failed, to rerun pass `--test auth`

Here the simple testfile:

// tests/my-int.rs
#[dtor]
fn on_shutdown() {
    tokio::runtime::Builder::new_current_thread()
        .enable_all()
        .build()
        .unwrap()
        .block_on(async {
            println!("HELLO WORLD");
        });
}

I'm not sure where the origin of this problem is. Is it a ctor problem or a problem of a other specific async library?
Here you see the diff of my Cargo.lock:
https://www.diffchecker.com/N8nESogY/

Sorry for the form, but I found no better solution to provide the differences, without copying them step by step.

T

[Tockra]

After some try and error I found out it worked until tokio 1.38.0
With 1.39.1 the error occurs.

Here is a minimal example. Just type cargo test and see the above code failing:
(Without fixed Cargo.lock):
https://github.com/Tockra/playground/tree/dtor-no-changes-not-working

(With fixed Cargo.lock, working):
https://github.com/Tockra/playground/tree/dtor-downgraded-tokio-working

• Problem occurs with M2 macbook on macos.
• No problem with X86 CPU on windows:
• Problem occurs on X86 Debian GNU/Linux 11 system

[mmastrac]

Unfortunately this is a life-before- and life-after-main issue. I'll leave this open as there should be some documentation on this.

[irbull]

I've hit this too. I'm using this with testcontaineres to clean up the containers when the tests finish. @mmastrac You mentioned there should be some docs, do you have any pointers to what those docs should be? I'd be happy to put a PR together, or at least help put one together.

[Darksonn]

From my point of view as a Tokio maintainer, using Tokio in #[ctor] or #[dtor] is completely unsupported. See the warning from ctor's readme:

The code that runs in the ctor and dtor functions should be careful to limit itself to libc functions and code that does not rely on Rust's stdlib services.

Using Tokio definitely counts as relying on Rust's stdlib services.

[mmastrac]

@irbull I think README.md is the best place for it. Happy to accept PRs for it. It may be difficult to find precise information on restrictions -- the Rust developers don't take this possibility into account, and therefore it's just likely that things break from version to version with no guarantees whatsoever.

I think this might be a good opportunity to bring up a better-supported solution than this crate with the Rust team itself. There's clearly enough interest in the concept that it might be useful to start the discussion on how this functionality can roll into the Rust project itself.