Skip to content

Fix continuation names appearing wrong in SOS debugger#121010

Merged
jkotas merged 2 commits intomainfrom
copilot/fix-continuation-names-sos-again
Oct 23, 2025
Merged

Fix continuation names appearing wrong in SOS debugger#121010
jkotas merged 2 commits intomainfrom
copilot/fix-continuation-names-sos-again

Conversation

Copy link
Contributor

Copilot AI commented Oct 23, 2025 •
edited
Loading

Summary

Fixes continuation names appearing incorrectly in SOS debugger by using DAC-aware pointer types in PrintContinuationName.

Problem

When debugging with SOS, continuation method table names displayed incorrectly with garbage data:

0:009> !do poi(@rbp-0x50)
Name:        Continuation_32_2714363008_9_0_3
MethodTable: 00007ff8a1c9e4b8

However, the internal debug_m_szClassName showed the correct name:

debug_m_szClassName : 0x00007ff8`a1c9e588  "Continuation_32_0_3"

Root Cause

The PrintContinuationName template function in asynccontinuations.h was using raw C++ pointers (CGCDesc* and CGCDescSeries*) instead of DAC-aware pointer types (PTR_CGCDesc and PTR_CGCDescSeries). This caused incorrect memory reads when the function was called from debugging contexts like SOS.

Solution

Updated the three pointer declarations in PrintContinuationName to use DAC-aware types:

  • CGCDesc* desc → PTR_CGCDesc desc
  • CGCDescSeries* lowestSeries → PTR_CGCDescSeries lowestSeries
  • CGCDescSeries* curSeries → PTR_CGCDescSeries curSeries

The PTR_ wrappers provide proper memory access semantics when reading data structures across process boundaries in debugging scenarios, ensuring SOS can correctly read GC descriptor information and display the proper continuation names.

Testing

  • CoreCLR builds successfully with the changes
  • No runtime behavior changes - only affects debugging scenarios
  • CodeQL security analysis passed

Fixes #<issue_number>

Original prompt

This section details on the original issue you should resolve

<issue_title>Continuation names appear wrong in SOS</issue_title>
<issue_description>E.g.:

0:009> !do poi(@rbp-0x50)
Name:        Continuation_32_2714363008_9_0_3
MethodTable: 00007ff8a1c9e4b8
Canonical MethodTable: 00007ff8a1c9a678
Tracked Type: false
Size:        72(0x48) bytes
File:        C:\dev\dotnet\runtime2\artifacts\tests\coreclr\windows.x64.Debug\Tests\Core_Root\System.Private.CoreLib.dll
Fields:
None

Things look right for the internal name:

0:009> ?? *(MethodTable*)0x00007ff8a1c9e4b8
class MethodTable
   =00007ff9`017b5760 s_pMethodDataCache : 0x00000238`ea8a1ea0 MethodDataCache
   +0x000 m_dwFlags        : 0x1000000
   +0x004 m_BaseSize       : 0x48
   +0x008 m_dwFlags2       : 0
   +0x00c m_wNumVirtuals   : 4
   +0x00e m_wNumInterfaces : 0
   +0x010 debug_m_szClassName : 0x00007ff8`a1c9e588  "Continuation_32_0_3"
   +0x018 m_pParentMethodTable : 0x00007ff8`a1c981c0 MethodTable
   +0x020 m_pModule        : 0x00007ff8`a1554000 Module
   +0x028 m_pAuxiliaryData : 0x00007ff8`a1c9e528 MethodTableAuxiliaryData
   +0x030 m_pEEClass       : 0x00007ff8`a1c9a5d0 EEClass
   +0x030 m_pCanonMT       : 0x00007ff8`a1c9a5d0
   +0x038 m_pPerInstInfo   : (null) 
   +0x038 m_ElementTypeHnd : 0
   +0x040 m_pInterfaceMap  : (null) 
   +0x040 m_encodedNullableUnboxData : 0

@noahfalk @jkotas Any idea what could be wrong here? Is the way I access GC descs in AsyncContinuationsManager::PrintContinuationName wrong?</issue_description>

Comments on the Issue (you are @copilot in this section)

@jakobbotsch Ah.. The raw pointers in `PrintContinuationName` should use the `PTR_` equivalents.

Fixes #121008

💡 You can make Copilot smarter by setting up custom instructions, customizing its development environment and configuring Model Context Protocol (MCP) servers. Learn more Copilot coding agent tips in the docs.

@github-actions github-actions bot added the needs-area-label An area label is needed to ensure this gets routed to the appropriate area owners label Oct 23, 2025
@jakobbotsch
Fix continuation names in SOS by using PTR_ types
373f367 
Co-authored-by: jakobbotsch <7887810+jakobbotsch@users.noreply.github.com>
Copilot AI changed the title [WIP] Fix wrong continuation names in SOS Fix continuation names appearing wrong in SOS debugger Oct 23, 2025
Copilot AI requested a review from jakobbotsch October 23, 2025 10:09
@KalleOlaviNiemitalo
Copy link

KalleOlaviNiemitalo commented Oct 23, 2025 •
edited
Loading

This is the exact same change as in #121009; the same tree 144741b2a29064de67474257541e86426e4b4db6 in both. https://github.com/dotnet/runtime/compare/copilot/fix-continuation-names-sos..copilot/fix-continuation-names-sos-again

@jakobbotsch
Copy link
Member

jakobbotsch commented Oct 23, 2025 •
edited
Loading

@KalleOlaviNiemitalo Thanks -- I closed #121009.
The first time I tried assigning copilot to the issue there was a GitHub error, so I had to retry. But seems like the first one still went through far enough to get copilot started.

@jakobbotsch jakobbotsch added area-Diagnostics-coreclr runtime-async and removed needs-area-label An area label is needed to ensure this gets routed to the appropriate area owners labels Oct 23, 2025
@dotnet-policy-service
Copy link
Contributor

dotnet-policy-service bot commented Oct 23, 2025

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

@jkotas jkotas marked this pull request as ready for review October 23, 2025 14:06
Copilot AI review requested due to automatic review settings October 23, 2025 14:06
Copilot AI reviewed Oct 23, 2025
View reviewed changes
Copy link
Contributor

Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull Request Overview

This PR fixes a bug where continuation method table names displayed incorrectly with garbage data in the SOS debugger. The root cause was the use of raw C++ pointers instead of DAC-aware pointer types when reading GC descriptor information across process boundaries during debugging.

Key Changes:

  • Updated PrintContinuationName function to use DAC-aware pointer types (PTR_CGCDesc and PTR_CGCDescSeries) instead of raw pointers
  • This ensures proper memory access semantics when SOS reads data structures across process boundaries

@jkotas jkotas merged commit dac11e0 into main Oct 23, 2025
105 checks passed
@jkotas jkotas deleted the copilot/fix-continuation-names-sos-again branch October 23, 2025 14:07
@dotnet-maestro dotnet-maestro bot mentioned this pull request Oct 23, 2025
Merged
@github-actions github-actions bot locked and limited conversation to collaborators Nov 23, 2025
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Reviewers

Copilot code review Copilot Copilot left review comments

@jkotas jkotas jkotas approved these changes

+1 more reviewer

@jakobbotsch jakobbotsch jakobbotsch approved these changes

Reviewers whose approvals may not affect merge requirements

Assignees

@jakobbotsch jakobbotsch

Copilot code review Copilot

Labels

area-Diagnostics-coreclr runtime-async

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

Continuation names appear wrong in SOS

5 participants

@KalleOlaviNiemitalo @jakobbotsch @jkotas