println! sometimes panics in drop methods

[sorear]

View all comments

If you try to println!-debug a drop method in a type which is being used in TLS, you can have problems because the TLS variable which holds the local stdout might already have been destroyed, turning your innocent print into a panic with "cannot access a TLS value during or after it is destroyed". This seems unnecessarily user-hostile.

(I solved the bug in my code, but I'm kinda curious what the recommended way to trace a drop method is. rt::util::dumb_print?)

[nagisa]

The issue here is that we initialise TLS variables lazily (AFAIR), but they still get dropped in order (of initialisation). If you happen to initialise your droppable type before whatever println! stores in the TLS, you will encounter this error.

A simple solution would be to somehow ensure that types which depend on TLS in their Drop get initialised latest… Sadly we do not have any means to figure out such dependencies.

[alexcrichton]

Sounds bad! I think we just need to add a check to see if TLS is already destroyed: #29491

[ranma42]

@nagisa I am afraid that we do not have any kind of guarantee about the order in which TLS variables are destroyed.

@alexcrichton We might also want to sanitise std to ensure that this issue does not affect other code. This has already been done for stderr and thread_info and it is now being done to stdout.
AFAICT thread_local! is also used in src/libstd/rand/mod.rs; I guess it is not very likely to call it directly from a Drop implementation, but it could still happen if some (complex) data structures were using while dropping.

[alexcrichton]

That's a good point about an audit! We probably don't need to worry much about rand as it's not an exported interface of the standard library, however, but probably good to fixup nonetheless!

[da-x]

If I improve the test case by adding: FOO.with(|_| {}); as the first line in main(), I get:

thread 'main' panicked at 'cannot access stdout during shutdown', src/libcore/option.rs:874:4
note: Run with `RUST_BACKTRACE=1` for a backtrace.
fatal runtime error: failed to initiate panic, error 5

(rustc 1.23.0)

It's the same if I add another FOO2 : Foo TLS and access it from main in the same way.

My question is, shouldn't stdout handling in TLS be symmetrical with regard to the main thread compared to threads created during runtime? @alexcrichton

[DustinByfuglien]

There is another case when applications panic while using drop/TLS/println:

struct Foo {}

impl Drop for Foo {
    fn drop(&mut self) {
        println!("drop begin");
    }
}


thread_local! {
    static FOO: Foo = Foo{};
}


fn main() {
    println!("main begin");
    FOO.with(|_| {});
}

This code output is:

main begin
thread '<unnamed>' panicked at 'cannot access stdout during shutdown', libcore\option.rs:916:5

My point of view is it also must be fixed in Rust language.

rustc 1.26.0-nightly (adf2135 2018-03-17)

[emilyalbini]

Seems like this is happening again?

[sfackler]

My question is, shouldn't stdout handling in TLS be symmetrical with regard to the main thread compared to threads created during runtime?

We don't control the TLS implementation unfortunately.

[DustinByfuglien]

Bug is critical as rust is panic. I think the I-ICE label must be added.
But I have no privilegies for this.
Can someone add I-ICE, A-thread-locals and A-destructors please?