Uh oh!
There was an error while loading. Please reload this page.
Runtime-async continuation object reading with Cordb - #121432
Conversation
Tagging subscribers to this area: @steveisok, @dotnet/dotnet-diag |
There was a problem hiding this comment.
Pull Request Overview
This PR adds special handling for continuation types in the debugger to map them to their base continuation class type for debugging purposes. The variable name "IfSubTypeCreated" suggests this is a lazily-initialized global that may be NULL before any continuation subtypes are created.
- Adds checks for continuation types using
IsContinuation()in debugger type conversion functions - Replaces continuation subtypes with the base continuation class type (
g_pContinuationClassIfSubTypeCreated) for debugger type information - Applies this pattern consistently across both EE debugger and DAC debugger interface implementations
Reviewed Changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 4 comments.
| File | Description |
|---|---|
| src/coreclr/debug/ee/debugger.cpp | Adds continuation type handling in TypeHandleToBasicTypeInfo and TypeHandleToExpandedTypeInfo to replace continuation types with base class |
| src/coreclr/debug/daccess/dacdbiimpl.cpp | Adds continuation type handling in GetClassTypeInfo and TypeHandleToBasicTypeInfo (DAC version) with same replacement pattern |
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
rcj1
commented
Dec 1, 2025
/ba-g unrelated fails |
This PR ensures that we are able to access continuation objects through APIs such as CordbObjectValue::GetFieldValue. As the dynamically generated continuation types with the local variable fields do not have metadata, we use the parent class which does have metadata. We will therefore not be able to view the locals fields through these APIs, but with the low likelihood that someone is digging this deep into implementation details, this should be an acceptable trade-off.