Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Double-panic when thread local drop eprintlns (only with stable 1.43.0) #71536

Closed
vakaras opened this issue Apr 24, 2020 · 2 comments
Closed
Labels
C-bug Category: This is a bug.

Comments

@vakaras
Copy link
Contributor

vakaras commented Apr 24, 2020

The example below double-panics (segfaults) with stable 1.43.0, but I cannot see any reason why this should happen.

I am not sure whether this is already fixed or not because I could reproduce it only with the latest stable version of the Rust compiler, but not with nightly or beta. However, I could not find any related issue on the issue tracker, so decided to open a new one.

I tried this code (playground):

struct TestCell {}

impl Drop for TestCell {
    fn drop(&mut self) {
        eprintln!("Dropping")
    }
}

thread_local! {
    static A: TestCell = TestCell {};
}

fn main() {
    A.with(|_| {});
    eprintln!("Continue main.")
}

I expected the program to print the following as it does with nightly and beta versions of the compiler:

Continue main.
Dropping

Instead, I get the following output:

Continue main.
thread panicked while processing panic. aborting.
fish: “./test” terminated by signal SIGILL (Illegal instruction)

Meta

I can reproduce the bug only on the stable version of the compiler.

rustc --version --verbose:

rustc 1.43.0 (4fb7144ed 2020-04-20)
binary: rustc
commit-hash: 4fb7144ed159f94491249e86d5bbd033b5d60550
commit-date: 2020-04-20
host: x86_64-unknown-linux-gnu
release: 1.43.0
LLVM version: 9.0
@vakaras vakaras added the C-bug Category: This is a bug. label Apr 24, 2020
@Mark-Simulacrum
Copy link
Member

I expect this was fixed by either #69959 or #69955, most likely the latter. In any case, given that beta/nightly work I'm going to go ahead and close since it seems like it's not a bug any more at least.

@vakaras
Copy link
Contributor Author

vakaras commented Apr 26, 2020

Thank you for pointing out the relevant PRs!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-bug Category: This is a bug.
Projects
None yet
Development

No branches or pull requests

2 participants