Repository navigation
Panics don't lock stderr while printing panic info #124995
Description
Panics don't seem to lock stderr while printing, so if multiple threads panic at once, this will happen:
thread 'thread 'thread 'thread 'State runner 5 (sync)State runner 1 (sync)State runner 0 (sync)State runner 4 (sync)' panicked at ' panicked at ' panicked at ' panicked at src/circuits/relay.rssrc/circuits/relay.rssrc/circuits/relay.rssrc/circuits/relay.rs::::167167167167::9::9:
99:
not yet implemented:
:
not yet implemented
not yet implementednot yet implemented
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
As you can see, i forgot a todo!() in the code and 4 threads executed it at the same time
Meta
rustc --version --verbose:
rustc 1.79.0-nightly (ccfcd950b 2024-04-15)
binary: rustc
commit-hash: ccfcd950b333fed046275dd8d54fe736ca498aa7
commit-date: 2024-04-15
host: x86_64-unknown-linux-gnu
release: 1.79.0-nightly
LLVM version: 18.1.3
Activity
workingjubilee commentedon May 11, 2024
hmm. I believe they do lock, as all instances of
eprintln!("{}", message)do. but they then release the lock, and that causes the result you see. it's not clear that we should change the way it currently works by default. I know that rustc did it for its panic infrastructure, but rustc is a very opinionated Rust program.the8472 commentedon May 11, 2024
The panic hook creates a new stderr handle that does not lock
rust/library/std/src/sys/pal/unix/stdio.rs
Lines 97 to 99 in 78a7751
That's probably intentional to not deadlock during error reporting and to get last-gasp errors out as fast as possible. "probably" because I don't know the original motivation, but I think the current behavior is reasonable.
#122565 will coalesce more of the panic output writes into a single buffer, which will reduce tearing.
workingjubilee commentedon May 11, 2024
oh, okay! I stand corrected.
the manual-coalescing behavior done there does seem like a slightly better move than going for locking.
Enselic commentedon Jul 7, 2025
Triage: Sounds like we want to keep things the way they are? I agree and suggest we close this as "won't fix" so we don't risk getting more deadlock problems (scary example: #130187).
the8472 commentedon Jul 7, 2025
We could try adding a try_lock to opportunistically exclude other, non-panicking writers, but I'm not sure if that's worth it.