Print thread ID in panic message #115746

tgross35 · 2023-09-11T05:19:01Z

panic! does not print any identifying information for threads that are
unnamed. However, in many cases, the thread ID can be determined.

This changes the panic message from something like this:

thread '<unnamed>' panicked at src/main.rs:3:5:
explicit panic

To something like this:

thread '<unnamed>' (12345) panicked at src/main.rs:3:5:
explicit panic

Stack overflow messages are updated as well.

This change applies to both named and unnamed threads. The ID printed is
the OS integer thread ID rather than the Rust thread ID, which should
also be what debuggers print.

try-job: dist-x86_64-freebsd
try-job: dist-x86_64-linux
try-job: dist-x86_64-linux-alt
try-job: dist-x86_64-netbsd

rustbot · 2023-09-11T05:19:09Z

r? @davidtwco

(rustbot has picked a reviewer for you, use r? to override)

tgross35 · 2023-09-11T05:19:52Z

I think this needs FCP since it's a visible change

@rustbot label -T-libs -T-compiler +T-libs-api
r? libs-api

rustbot · 2023-09-11T05:35:09Z

The Miri subtree was changed

cc @rust-lang/miri

tgross35 · 2023-09-11T06:21:00Z

cc @m-ou-se since you recently did the formatting in #112849

bjorn3 · 2023-09-11T08:16:28Z

Maybe

thread '<unnamed 2>' panicked at src/main.rs:3:5:
explicit panic

or

thread '<unnamed#2>' panicked at src/main.rs:3:5:
explicit panic

? That fits more with the way named threads are shown.

the8472 · 2023-09-11T09:22:55Z

Note that this is a rust-internal thread ID, which isn't the OS thread ID which can be relevant if you're also logging from C code or looking at things with GDB. And as_u64() is unstable and there are questions about stabilizing it (#110738).

tgross35 · 2023-09-11T10:04:18Z

Maybe

thread '<unnamed 2>' panicked at src/main.rs:3:5:
explicit panic

or

thread '<unnamed#2>' panicked at src/main.rs:3:5:
explicit panic

I just proposed the syntax as a demo, figured libs-api would make the final choice - though between those two, I like the first one better

Note that this is a rust-internal thread ID, which isn't the OS thread ID which can be relevant if you're also logging from C code or looking at things with GDB. And as_u64() is unstable and there are questions about stabilizing it (#110738).

It is kind of unfortunate that Rust and C won't use the same thread IDs. But this seems worthwhile still - Rust-only applications printing the thread ID in logs is common (tracing even has a builtin way to do this), probably more common than Rust thread IDs silently mixing with C thread IDs in logs. And even in that case, it still gives you something more concrete to trace than "something failed".

This is all inspired by the below failure I recently had in an highly threaded system. The entire backtrace uselessly displayed one repeated function, with no hints about which preceding log events were relevant:

thread '<unnamed>' panicked at src/scan.rs:101:55:
called `Result::unwrap()` on an `Err` value: ()
stack backtrace:
   0:        0x1009661d0 - __mh_execute_header
   1:        0x10088869b - __mh_execute_header
   2:        0x10093ba0e - __mh_execute_header
   4:        0x10096757c - __mh_execute_header
   5:        0x100968632 - __mh_execute_header
   6:        0x1009680f4 - __mh_execute_header
   7:        0x100968059 - __mh_execute_header
   8:        0x100968042 - __mh_execute_header
   9:        0x100bdd913 - __mh_execute_header

I don't think that stability of the thread ID is much of a concern since we will always have some integer ID for a thread, even if the semantics of that ID might change. The important thing is probably just that this panic message thread ID is the same as what shows up as Debug for ThreadId (or as_u64 as applicable) since that is what other libraries are directed to use. That is the case here

tgross35 · 2023-09-15T07:18:44Z

Another display option - it looks a bit cleaner to not even call out that a thread is unnamed, and I don't think it adds much

thread with ID 2 panicked at src/main.rs:3:5:
explicit panic

Or we could use ThreadId's debug formatting which tracing and I think log do, but that seems unnecessarily clunky

thread with `ThreadId(2)` panicked at src/main.rs:3:5:
explicit panic

I also tried to poke some discussion at #67939

bors · 2023-09-19T19:48:12Z

☔ The latest upstream changes (presumably #115627) made this pull request unmergeable. Please resolve the merge conflicts.

tgross35 · 2023-10-23T23:50:36Z

@joshtriplett do you have any thoughts on this?

timClicks · 2023-11-10T03:02:51Z

Sorry to add bike shedding to the thread. Here is a slight derivative of the last suggestion, which omits a "with":

thread `ThreadId(2)` panicked at src/main.rs:3:5:
explicit panic

Although it's uglier than using the thread identifier in a sentence, using the Debug form makes it look like a Rust value rather than something else. It's also consistent with other output from Rust, although the case can definitely be made that thread IDs deserve a special case.

tgross35 · 2023-12-01T05:35:09Z

I know Josh has a pretty busy queue, so perhaps it is best to reroll

r? libs-api

dtolnay · 2023-12-01T06:37:52Z

I think this needs FCP since it's a visible change

@rustbot label -T-libs -T-compiler +T-libs-api

I think it wouldn't need one. T-libs-api FCP is primarily for any time a permanent API commitment is being made by the standard library, and deprecations. In contrast, anything that we can just change back with minimal effort or disruption would not warrant FCP.

#112849 had a T-libs FCP but I am not familiar with their criteria for that. @rust-lang/libs would you want to handle this PR?

In any case, this looks good to me.

thomcc · 2023-12-01T06:44:15Z

I don't know that this needs FCP. I'm not opposed and there is precedent for it, but OTOH we wouldn't FCP a panic message change somewhere in the stdlib. So I don't feel strongly.

In any case, I think this change is a good idea, and am in favor.

tgross35 · 2025-06-13T22:16:44Z

library/std/src/sys/pal/windows/thread.rs

@@ -115,6 +115,14 @@ impl Thread {
    }
 }

+pub(crate) fn current_os_id() -> Option<u64> {
+    // SAFETY: FFI call with no preconditions.
+    let id: u32 = unsafe { c::GetThreadId(c::GetCurrentThread()) };


I am going to change this to GetCurrentThreadId that does both steps, but not until the Miri shims merge so I can stop manually syncing changes.

Print thread ID in panic message `panic!` does not print any identifying information for threads that are unnamed. However, in many cases, the thread ID can be determined. This changes the panic message from something like this: thread '<unnamed>' panicked at src/main.rs:3:5: explicit panic To something like this: thread '<unnamed>' (12345) panicked at src/main.rs:3:5: explicit panic Stack overflow messages are updated as well. This change applies to both named and unnamed threads. The ID printed is the OS integer thread ID rather than the Rust thread ID, which should also be what debuggers print. try-job: `*various*` try-job: `x86_64-msvc*`

Print thread ID in panic message `panic!` does not print any identifying information for threads that are unnamed. However, in many cases, the thread ID can be determined. This changes the panic message from something like this: thread '<unnamed>' panicked at src/main.rs:3:5: explicit panic To something like this: thread '<unnamed>' (12345) panicked at src/main.rs:3:5: explicit panic Stack overflow messages are updated as well. This change applies to both named and unnamed threads. The ID printed is the OS integer thread ID rather than the Rust thread ID, which should also be what debuggers print. try-job: aarch64-gnu try-job: test-various try-job: x86_64-gnu try-job: x86_64-gnu-aux try-job: x86_64-msvc-1

tgross35 · 2025-06-14T19:07:28Z

@bors2 try

rust-bors · 2025-06-14T19:07:32Z

⌛ Trying commit a08fb17 with merge 2591081…

To cancel the try build, run the command @bors2 try cancel.

Print thread ID in panic message `panic!` does not print any identifying information for threads that are unnamed. However, in many cases, the thread ID can be determined. This changes the panic message from something like this: thread '<unnamed>' panicked at src/main.rs:3:5: explicit panic To something like this: thread '<unnamed>' (12345) panicked at src/main.rs:3:5: explicit panic Stack overflow messages are updated as well. This change applies to both named and unnamed threads. The ID printed is the OS integer thread ID rather than the Rust thread ID, which should also be what debuggers print. try-job: x86_64-msvc-1 try-job: `x86_64-mingw-*`

rust-bors · 2025-06-14T21:41:28Z

☀️ Try build successful (CI)
Build commit: 2591081 (2591081df6a34c230b27998270b2e49294c7aa24, parent: 4a73e3c224465c0c0e71b39b479a0911460dd794)

cuviper · 2025-06-17T00:46:12Z

library/std/src/sys/pal/unix/thread.rs

+        // Most platforms have a function returning a `pid_t` or int, which is an `i32`.
+        if #[cfg(any(target_os = "android", target_os = "linux", target_os = "nto"))] {
+            // SAFETY: FFI call with no preconditions.
+            let id: libc::pid_t = unsafe { libc::gettid() };


This is too new for our baseline on linux-gnu targets, glibc 2.17 vs gettid@GLIBC_2.30, but SYS_gettid goes way back to kernel 2.4.11, so using the syscall! macro should have no trouble.

(I expect the dist jobs would have uncovered this too, simply failing to link with their older sysroots.)

I have no idea about baseline availability on most of the other targets though.

Thanks for the catch. I just did a quick breeze through the others:

OpenBSD: added in 2014 (unsure of specific version) openbsd/src@cbcba41

FreeBSD: added in 2011 / 9.0 freebsd/freebsd-src@678b238

NetBSD since 2003 (unsure of specific version) https://github.com/NetBSD/src/blame/d0905be2d3efc632b786a696905d9a3ba646a6ec/include/lwp.h#L47

Apple - unsure how to check this but this man page says 10.12.3, which matches our 10.12 minimum https://www.manpagez.com/man/3/pthread_threadid_np/

So I think the rest should be fine here.

Updated Linux to use the syscall.

For Neutrino, based on rust-lang/libc@720151f gettid is supported at least since 7.1. I updated nto to only be enabled on 7.1+ but just in case @jonathanpallant any idea if gettid is actually available in 7.0 as well?

This PR still needs the Miri changes to merge first, but @cuviper is the current design enough to resolve the concern (link) and get FCP started?

Cc @joshtriplett since you registered the concern.

cuviper · 2025-06-17T00:52:31Z

src/tools/miri/tests/panic/mir-validation.rs

+// FIXME: output is different between stage1 and stage2. This should be possible to remove
+// when stages get bumped.
+// For the grep: cfg(bootstrap)
+//@normalize-stderr-test: "thread 'rustc' panicked" -> "thread 'rustc' ($$TID) panicked"


Is this still true after the stage0 redesign? Which library is getting used here?

Seemingly so; I needed this in my most recent push which was based on master from ~3 days ago. The same for tests/ui/track-diagnostics/track.rs, I'm less certain about what might be going on there.

Cc @rust-lang/bootstrap in case you have any ideas. For context, it seems like stage1 at the test here, as well as for track-diagnostics/track.rs, may be getting run with beta or nightly std rather than in-tree.

I'll take a look at what stdlib is being used.

Locally track-diagnostics/track.rs runs with stage 1 stdlib, at least with ./x test tests/ui/track-diagnostics/track.rs. I'll check the miri test.

Just to confirm from testing locally; if I remove the normalize in track.rs, ./x test tests/ui/track-diagnostics/track.rs fails but ./x test --stage 2 tests/ui/track-diagnostics/track.rs succeeds. I think this one failed in CI as well but I don't recall for sure.

The Miri test I know for sure failed both locally and in CI without the workaround.

Oh, wait, this makes sense doesn't it; everything that is a panic during runtime is using the in-tree compiler, so the output change will show up in the tests immediately. But the two tests here are panics in rustc at comptime, and that rustc was built using downloaded std so it won't have the update - at least until stage 2.

So having the normalize step here is expected to be needed (or somehow skipping the test for stage1), I was just getting myself confused around the redesign and thinking it shouldn't be necessary.

Updated the comment to make this more clear

tgross35 · 2025-06-18T00:36:30Z

@bors2 try

rust-bors · 2025-06-18T00:36:34Z

⌛ Trying commit 2a45bec with merge cd6ce31…

To cancel the try build, run the command @bors2 try cancel.

Print thread ID in panic message `panic!` does not print any identifying information for threads that are unnamed. However, in many cases, the thread ID can be determined. This changes the panic message from something like this: thread '<unnamed>' panicked at src/main.rs:3:5: explicit panic To something like this: thread '<unnamed>' (12345) panicked at src/main.rs:3:5: explicit panic Stack overflow messages are updated as well. This change applies to both named and unnamed threads. The ID printed is the OS integer thread ID rather than the Rust thread ID, which should also be what debuggers print. try-job: dist-x86_64-freebsd try-job: dist-x86_64-linux try-job: dist-x86_64-linux-alt try-job: dist-x86_64-netbsd

rustbot assigned davidtwco Sep 11, 2023

rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-libs Relevant to the library team, which will review and decide on the PR/issue. labels Sep 11, 2023

rustbot added T-libs-api Relevant to the library API team, which will review and decide on the PR/issue. and removed T-libs Relevant to the library team, which will review and decide on the PR/issue. labels Sep 11, 2023

rustbot assigned joshtriplett and unassigned davidtwco Sep 11, 2023

tgross35 force-pushed the unnamed-threads-panic-message branch from d68fab6 to 371dd28 Compare September 11, 2023 05:35

tgross35 force-pushed the unnamed-threads-panic-message branch 2 times, most recently from 8e72037 to 3da1046 Compare September 11, 2023 06:13

rustbot removed the T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. label Sep 11, 2023

tgross35 force-pushed the unnamed-threads-panic-message branch from 3da1046 to e055544 Compare November 9, 2023 17:20

rustbot assigned dtolnay and unassigned joshtriplett Dec 1, 2023

dtolnay approved these changes Dec 1, 2023

View reviewed changes

tgross35 commented Jun 13, 2025

View reviewed changes

tgross35 added 3 commits June 13, 2025 23:15

fixup! Print thread ID in panic message if thread name is unknown

8eeabd5

fixup! Add normalization for thread IDs in panic messages

ee6756b

fixup! Work around stage1 vs. stage2 differences in miri

589b87f

This comment was marked as outdated.

Sign in to view

fixup! Print thread ID in panic message if thread name is unknown

fd78223

rustbot added the O-SGX Target: SGX label Jun 14, 2025

This comment was marked as outdated.

Sign in to view

fixup! Print thread ID in panic message if thread name is unknown

a08fb17

cuviper reviewed Jun 17, 2025

View reviewed changes

tgross35 added 2 commits June 17, 2025 20:15

fixup! Work around stage1 vs. stage2 differences in miri

454c870

fixup! Print thread ID in panic message if thread name is unknown

2a45bec

Print thread ID in panic message #115746

Are you sure you want to change the base?

Print thread ID in panic message #115746

Conversation

tgross35 commented Sep 11, 2023 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

rustbot commented Sep 11, 2023

Uh oh!

tgross35 commented Sep 11, 2023 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

rustbot commented Sep 11, 2023

Uh oh!

tgross35 commented Sep 11, 2023

Uh oh!

bjorn3 commented Sep 11, 2023

Uh oh!

the8472 commented Sep 11, 2023

Uh oh!

tgross35 commented Sep 11, 2023 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

tgross35 commented Sep 15, 2023 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

bors commented Sep 19, 2023

Uh oh!

tgross35 commented Oct 23, 2023

Uh oh!

timClicks commented Nov 10, 2023

Uh oh!

tgross35 commented Dec 1, 2023

Uh oh!

dtolnay commented Dec 1, 2023

Uh oh!

thomcc commented Dec 1, 2023

Uh oh!

Choose a reason for hiding this comment

Uh oh!

This comment was marked as outdated.

This comment was marked as outdated.

This comment was marked as outdated.

This comment was marked as outdated.

This comment was marked as outdated.

This comment was marked as outdated.

This comment was marked as outdated.

This comment was marked as outdated.

This comment was marked as outdated.

tgross35 commented Jun 14, 2025

Uh oh!

rust-bors bot commented Jun 14, 2025

Uh oh!

rust-bors bot commented Jun 14, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

tgross35 Jun 17, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

tgross35 Jun 17, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

tgross35 commented Sep 11, 2023 •

edited

Loading

tgross35 commented Sep 11, 2023 •

edited

Loading

tgross35 commented Sep 11, 2023 •

edited

Loading

tgross35 commented Sep 15, 2023 •

edited

Loading

tgross35 Jun 17, 2025 •

edited

Loading

tgross35 Jun 17, 2025 •

edited

Loading