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

(Only in release) fatal runtime error: assertion failed: thread_info.stack_guard.get().is_none() && thread_info.thread.get().is_none() #120728

Open
v0x0g opened this issue Feb 7, 2024 · 0 comments
Labels
C-bug Category: This is a bug.

Comments

@v0x0g
Copy link

v0x0g commented Feb 7, 2024

Background

I am working on a CPU ray-tracer, my project is called Rayna.

Compiler

rustc 1.76.0-nightly (21cce21d8 2023-12-11)
binary: rustc
commit-hash: 21cce21d8c012f14cf74d5afddd795d324600dac
commit-date: 2023-12-11
host: x86_64-pc-windows-msvc
release: 1.76.0-nightly
LLVM version: 17.0.5

Issue

Problem

Yesterday, I tried to run my code in release so I could do some profiling on some code I had just run in dev. The program would not start, and kept crashing with:


fatal runtime error: assertion failed: thread_info.stack_guard.get().is_none() && thread_info.thread.get().is_none()
error: process didn't exit successfully: `target\release\rayna_ui.exe` (exit code: 0xc0000409, STATUS_STACK_BUFFER_OVERRUN)

Stacktrace

This is the stacktrace from the debugger (RustRover). Setting RUST_BACKTRACE=1 does not seem to change the output or give a stacktrace

[Inlined] std::thread::local::LocalKey::try_with() local.rs:270
[Inlined] std::thread::local::LocalKey::with() local.rs:246
std::sys_common::thread_info::set() thread_info.rs:44
[Inlined] std::rt::init() rt.rs:105
[Inlined] std::rt::lang_start_internal::closure$1() rt.rs:147
[Inlined] std::panicking::try::do_call() panicking.rs:552
[Inlined] std::panicking::try() panicking.rs:516
[Inlined] std::panic::catch_unwind() panic.rs:142
[Inlined] std::rt::lang_start_internal() rt.rs:147
std::rt::lang_start<enum2$<core::result::Result<tuple$<>,anyhow::Error> > >(*mut ,i64,*mut *mut u8,u8) rt.rs:166
[Inlined] invoke_main() 0x00007ff70744005c
__scrt_common_main_seh() 0x00007ff70744003a
<unknown> 0x00007ffe20be257d
<unknown> 0x00007ffe2248aa58

Screenshot 2024-02-06 194225

Thoughts

Build Profile Oddities

The odd thing is that my code works perfectly fine with --profile=dev, but crashes with --profile=release. I have no idea why, and I am running the exact same copy of my code, only the build profile changes. Also, I have attempted to clean all build artifacts in case some were corrupted, but that has not changed anything.

Previous Issues

I have had this issue a few times before in the past few weeks, but oddly when the previous issues happened, simply executing cargo run again would work fine (without recompiling, just running the program again).

Threads

The issue appears to be happening before my main function is executing. There are a lot of threads: main, 3x ntdll.dll, and 20x rayna_ui.exe!std::sys::windows::thread::impl$0::new::thread_start(). I wonder if it's linked to my use of the static_init crate, which I'm using to initialise some static variables before main(), but I have no evidence for this.

Screenshot 2024-02-07 134532

Reproducing

My current setup is reproducible:

  • Commit 41b1dcfca33034ab5cb98d6d2c5ea7d9194c9635 consistently causes the bug for me
  • Commit 0732551e1dc5f895f5837f3f69801c2fa7a424bf (removed crate static_init) consistently works fine

My repository setup is a little borked right now; I have a few repos that I have forked, and a few more that are not published to github. I am in the process of fixing this, and will post an update as soon as it is fixed. For now I will provide an online link to download a copy of the entire folder structure: https://drive.proton.me/urls/FJZ41HCGTR#Rok13riFviH3

@v0x0g v0x0g added the C-bug Category: This is a bug. label Feb 7, 2024
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

1 participant