Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[cdac] Clear cached data as part of IXCLRDataProcess::Flush #110700

Merged
merged 1 commit into from
Dec 14, 2024

Conversation

elinor-fung
Copy link
Member

@elinor-fung elinor-fung commented Dec 13, 2024

Found this while running the diagnostics repo SOS tests with the cDAC enabled. General sequence for the repro was:

!sethostruntime -none
!bpmd <firstLocation>
!bpmd <secondLocation>
g
g
!clrstack

Printed stack shows <unknown> for some method(s).

Between the first and second breakpoints, more methods were jitted and the corresponding code heap list updated. When a new method in the stack for <secondLocation> had the same code heap list as any method from <firstLocation>, we'd end up with a stale end address for the heap list and determine that the method was invalid (outside the address range).

The cdac was assuming that the target would be created every time the state changes, but that is not the case (for the repro above, !sethostruntime -none resulted in not re-creating the target). We need to handle IXCLRDataProcess::Flush calls to clear out any cached data.

With this change, the SOS tests with the cDAC enabled run successfully with both a Release and Debug cdacreader (on a Release runtime).

Contributes to #99302

Copy link
Contributor

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

@elinor-fung elinor-fung merged commit d6c034d into dotnet:main Dec 14, 2024
145 of 147 checks passed
@elinor-fung elinor-fung deleted the cdac-flush branch December 14, 2024 02:23
hez2010 pushed a commit to hez2010/runtime that referenced this pull request Dec 14, 2024
…10700)

Found this while running the diagnostics repo SOS tests with the cDAC enabled. General sequence for the repro was:
```
!sethostruntime -none
!bpmd <firstLocation>
!bpmd <secondLocation>
g
g
!clrstack
```
Printed stack shows `<unknown>` for some method(s).

Between the first and second breakpoints, more methods were jitted and the corresponding code heap list updated. When a new method in the stack for `<secondLocation>` had the same code heap list as any method from `<firstLocation>`, we'd end up with a stale end address for the heap list and determine that the method was invalid (outside the address range).

The cdac was assuming that the target would be created every time the state changes, but that is not the case (for the repro above, `!sethostruntime -none` resulted in not re-creating the target). We need to handle `IXCLRDataProcess::Flush` calls to clear out any cached data.

With this change, the SOS tests with the cDAC enabled run successfully with both a Release and Debug cdacreader (on a Release runtime).
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants