Open Bug 1362174 Opened 8 years ago Updated 3 years ago

Use SetThreadDescription on Windows 10

Categories

(Core :: General, defect)

Product:
Core
Component:
General
Platform:
Unspecified
Windows 10
Type:
defect

Tracking

()

People

(Reporter: away, Unassigned)

References

Details

Windows 10 starting in version 1607 has a new API for setting thread names: https://msdn.microsoft.com/en-us/library/windows/desktop/mt774976(v=vs.85).aspx This is better than the longstanding magic-number-exception trick because the description "sticks": you won't miss out on the thread name if you don't have a debugger attached at the time of the call. Any code that currently uses the magic number should be augmented with an additional SetThreadDescription on machines that support it: https://dxr.mozilla.org/mozilla-central/search?q=0x406d1388
Thanks for finding this out!
The major usage comes from _PR_MD_SET_CURRENT_THREAD_NAME in NSPR, fixing it will fix 99%. I think this should be a meta bug and each module should have it's own bug/patch filed under respective components.
Component: Build Config → General
Depends on: 1362976
> I think this should be a meta bug and each module should have it's own > bug/patch filed under respective components. Agreed, and I was planning to do so myself, but since this is not perf-related it is low priority for me right now. Thank you for taking on the NSPR piece!

NSPR now does use SetThreadDescription but debuggers still show thread numbers instead of their names. Should there be more work on this?

(In reply to Kagami :saschanaz from comment #4)

NSPR now does use SetThreadDescription but debuggers still show thread numbers instead of their names. Should there be more work on this?

Are you attaching to a running process? it may be that SetThreadDescription doesn't always work and the current code will only do the exception hacky thing which works only when the debugger (VS) is attached.

(In reply to Honza Bambas (:mayhemer) from comment #5)

Are you attaching to a running process? it may be that SetThreadDescription doesn't always work and the current code will only do the exception hacky thing which works only when the debugger (VS) is attached.

I tried both launching a new process and attaching to a running process but have never seen a named thread. It's interesting to see it uses w95thred.c instead of ntthread.c on Windows 10.

(In reply to Kagami :saschanaz from comment #6)

I tried both launching a new process and attaching to a running process but have never seen a named thread.

Could you try stepping through the code that calls SetThreadDescription? Do we even reach there? Is the function pointer nonnull?

It's interesting to see it uses w95thred.c instead of ntthread.c on Windows 10.

As a wild guess I'd say that might be ICF trickery.

It does call SetThreadDescription, and it does name the threads, but the names evaporate when the program resumes.

Wow. How strange!

Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.