Use SetThreadDescription on Windows 10
Categories
(Core :: General, 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
Comment 1•7 years ago
|
||
Thanks for finding this out!
Comment 2•7 years ago
|
||
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.
> 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!
Comment 4•4 years ago
|
||
NSPR now does use SetThreadDescription but debuggers still show thread numbers instead of their names. Should there be more work on this?
Comment 5•4 years ago
|
||
(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.
Comment 6•4 years ago
|
||
(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 ofntthread.c
on Windows 10.
As a wild guess I'd say that might be ICF trickery.
Comment 8•4 years ago
|
||
It does call SetThreadDescription, and it does name the threads, but the names evaporate when the program resumes.
Updated•2 years ago
|
Description
•