Fix stale lastThrownObjectHandle in DAC GetThreadData during active exception dispatch#127741
Fix stale lastThrownObjectHandle in DAC GetThreadData during active exception dispatch#127741hoyosjs merged 3 commits intodotnet:mainfrom
Conversation
|
@jkotas @max-charlamb - This was a regression when trying to update the last set of runtime changes in SOS tests |
|
Tagging subscribers to this area: @steveisok, @tommcdon, @dotnet/dotnet-diag |
There was a problem hiding this comment.
Pull request overview
This PR fixes debugger-visible exception reporting when the target is stopped mid-exception-dispatch by preferring the active exception stored in the ExInfo tracker (via a pseudo-handle to the exception slot) instead of relying on Thread::m_LastThrownObjectHandle, which can be stale during active dispatch after #127300.
Changes:
- Update native DAC
ClrDataAccess::GetThreadDatato return the active exception pseudo-handle when available, falling back tom_LastThrownObjectHandle. - Update the cDAC thread contract to compute
ThreadData.LastThrownObjectHandlefrom the activeExceptionInfo.ThrownObjectslot when present (same pseudo-handle semantics), with fallback.
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.
| File | Description |
|---|---|
| src/native/managed/cdac/Microsoft.Diagnostics.DataContractReader.Contracts/Contracts/Thread_1.cs | Prefer ExInfo-derived pseudo-handle for ThreadData.LastThrownObjectHandle; factor pseudo-handle computation into a helper used by both GetThreadData and GetCurrentExceptionHandle. |
| src/coreclr/debug/daccess/request.cpp | Prefer Thread::GetThrowableAsPseudoHandle() for DacpThreadData::lastThrownObjectHandle in GetThreadData, falling back to m_LastThrownObjectHandle. |
|
/ba-g cDAC issue is #127774 and other legs don't get touched by this PR for anything other than builds, so timeouts are unrelated |
After #127300 removed ExInfo::m_hThrowable and SetThrowable(), Thread::m_LastThrownObjectHandle is no longer updated during active exception dispatch. This causes a staleclastThrownObjectHandle to ge returned by GetThreadData when a debugger breaks into the target mid-dispatch.
When debugging a .NET 11 process with SOS (e.g. via dotnet-dump or WinDbg), the following commands fail if the debuggee is stopped during exception dispatch (for example, with SXE CLR):