[cDAC] Fix bug in GetThreadData

[rcj1]

We have to ensure that the thread is reported as dead when either Dead or ReportDead are set. There are, however, certain cases where it is useful to distinguish between the two, for example GetThreadOwningMonitorLock.

[dotnet-policy-service]

Tagging subscribers to this area: @steveisok, @tommcdon, @dotnet/dotnet-diag
See info in area-owners.md if you want to be subscribed.

[Copilot]

Pull request overview

This PR fixes cDAC thread “dead” semantics by treating ThreadState.ReportDead as dead for enumeration and IsThreadMarkedDead, while still allowing callers to distinguish Dead vs ReportDead when needed (e.g., monitor-lock ownership queries).

Changes:

• Update thread enumeration and IsThreadMarkedDead to consider ReportDead as dead.
• Extend the managed thread contract to surface ReportDead and convert runtime state bits into contract flags.
• Adjust Thread contract documentation to reflect that raw runtime state requires conversion to the contract enum.

Reviewed changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated 4 comments.

File	Description
src/native/managed/cdac/Microsoft.Diagnostics.DataContractReader.Legacy/Dbi/DacDbiImpl.cs	Treat ReportDead threads as dead for enumeration and IsThreadMarkedDead.
src/native/managed/cdac/Microsoft.Diagnostics.DataContractReader.Contracts/Contracts/Thread_1.cs	Add mapping from runtime Thread::State bits (incl. TS_ReportDead) into contract ThreadState.
src/native/managed/cdac/Microsoft.Diagnostics.DataContractReader.Abstractions/Contracts/IThread.cs	Add ThreadState.ReportDead to the public contract enum.
docs/design/datacontracts/Thread.md	Note that Thread::State should be converted to the contract enum rather than used as a raw integer.

[jkotas]

What does it mean "for the purpose of the debugger"?

[rcj1]

We set ReportDead before Dead to indicate that a thread is done with useful work and is in cleanup - that is, not interesting to a debugger.

runtime/src/coreclr/vm/threads.cpp

Line 836 in 1c60926

th->SetThreadState(Thread::TS_ReportDead);

Do you think we should or can combine the two under Dead? Aside from the debugger, we use the flag mostly for GC-related checks, and I'm not 100% sure if it'd be safe to do so.

[jkotas]

I would like to see the flag to be described in terms of invariants that it guarantees.

I understand Dead. it means that the thread is not going to run any managed code (nor native runtime code - except the very small amount of non-interesting unmanaged runtime code between this flag being set and return from the thread exit callback).

What are the invariants for ReportDead? I do not see anything that prevents ReportDead threads running managed code. If it has a fuzzy meaning "the thread is probably not going to do any interesting work and it is probably going to exit soon", we should document it as such. I wish we can come up with something more precise. I would be fine with adjusting the implementation to fit the more precise definition.

[jkotas]

Do you think we should or can combine the two under Dead?

Or delete the ReportDead flag. I am not sure.

You can give it a try and see what breaks to understand what the ReportFlag flag is actually used for.

[rcj1]

ReportDead is set in three places; immediately before thread destruction

runtime/src/coreclr/vm/threads.cpp

Line 836 in 76853ac

th->SetThreadState(Thread::TS_ReportDead);

, "on the main thread of an EXE, after that thread has finished doing useful work" before process termination

runtime/src/coreclr/vm/threads.cpp

Line 4397 in 76853ac

pCurThread->SetThreadState(Thread::TS_ReportDead);

, and on thread detach

runtime/src/coreclr/vm/threads.cpp

Line 914 in 76853ac

SetThreadState((Thread::ThreadState)(Thread::TS_Detached | Thread::TS_ReportDead));

. I am hesitant to remove it because this would mean the debugger would see these threads that are potentially in the middle of cleanup, and try to make sense of their structures. I believe we can document ReportDead as "this thread will not do more interesting work" and leave it at that.

[jkotas]

How about this:

• Delete the confusing remapping of TS_ReportDead to TS_Dead from GetSnapshotState and adjust callers accordingly. It should be fine to assume that any TS_Dead thread is TS_ReportedDead as well, so it should be sufficient to check for TS_ReportedDead instead of both bits. It is possible that cDAC won't actually need TS_Dead after this cleanup, I am not able to tell.

• Description for TS_ReportDead: TS_ReportDead is set when the thread starts shutting down and it is not expected to run managed code anymore. It corresponds to ThreadState.Stopped reported by the managed Thread.ThreadState API. Would it make sense to rename TS_ReportDead to TS_Stopped to make it clear that it is same as managed ThreadState.Stopped?

• Description for TS_Dead: TS_Dead is set after the .NET runtime finished shutting down the thread, and the OS is about to terminate the thread.

[rcj1]

This sounds good.

[max-charlamb]

lgtm

[Copilot]

Pull request overview

Copilot reviewed 16 out of 16 changed files in this pull request and generated 5 comments.

Comments suppressed due to low confidence (1)

src/coreclr/vm/comsynchronizable.cpp:408

• ThreadNative_GetThreadState now reads the raw m_State via GetState(), but still only treats TS_Dead as "stopped". Previously GetSnapshotState() ORed TS_Dead when the reporting bit was set (now TS_Stopped), so this will fail to report shutting-down threads as stopped. Update the condition to treat TS_Stopped (and likely TS_Dead as well) as ThreadStopped to preserve behavior.

    // grab a snapshot
    Thread::ThreadState state = thread->GetState();

    if (state & Thread::TS_Dead)
        res |= ThreadNative::ThreadStopped;

[Copilot]

Pull request overview

Copilot reviewed 17 out of 17 changed files in this pull request and generated 1 comment.

[jkotas]

Suggested change

// The TS_Stopped bit will cause the debugger to view this as TS_Dead.

Debugger sees TS_Stopped as TS_Stopped

[jkotas]

Thanks!