Summary

The native runtime's RangeSectionFragmentPointer (codeman.h) uses bit 0 of the Next pointer as a collectible flag for fragments belonging to collectible assembly load contexts. The cDAC was reading the raw tagged pointer without stripping this bit, causing reads at a misaligned address that produced garbage field values and VirtualReadException during stack walks.

Root Cause

In the native runtime, RangeSectionFragment nodes are linked via RangeSectionFragmentPointer, which stores a tagged pointer where bit 0 indicates whether the fragment belongs to a collectible ALC. The native code's VolatileLoadWithoutBarrier strips this bit before returning the fragment address. The cDAC's Data.RangeSectionFragment class was reading the raw Next field without stripping the bit. When following a linked list of fragments, the cDAC used the tagged address (off by 1 byte), causing all subsequent field reads to return garbage data.

Note: The cDAC already correctly strips the tag from interior map pointers via InteriorMapValue.Address and from the initial fragment pointer in FindFragment. Only the RangeSectionFragment.Next linked-list pointer was missed.

Fix

Strip bit 0 from the Next pointer when reading it in the RangeSectionFragment constructor:

Next = target.ReadPointer(address + (ulong)type.Fields[nameof(Next)].Offset) & ~1ul;

Testing

• Added GetMethodDesc_CollectibleFragmentNext regression test that creates a two-fragment chain where the head fragment's Next has the collectible tag bit set. The test fails without the fix (VirtualReadException) and passes with it.
• All 876 existing cDAC unit tests pass.
• Verified against a CI dump from a failing SOS.DualRuntimes test: all 15 threads now walk to completion.

Documentation

• Updated docs/design/datacontracts/ExecutionManager.md to document the tagged pointer convention on RangeSectionFragment.Next and added a "Tagged pointers in the range section map" subsection.