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

Restore original stack ref enumeration behavior #84034

Merged
merged 1 commit into from
Mar 28, 2023

Conversation

leculver
Copy link
Contributor

The previous change to ICorDebugGCReferenceEnum accidently inverted the logic for interior pointers.

The previous change to ICorDebugGCReferenceEnum accidently inverted the logic for interior pointers.
@ghost
Copy link

ghost commented Mar 28, 2023

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

Issue Details

The previous change to ICorDebugGCReferenceEnum accidently inverted the logic for interior pointers.

Author: leculver
Assignees: leculver
Labels:

area-Diagnostics-coreclr

Milestone: -


const SOSStackRefData &sosStackRef = mList.Get(i);
if (sosStackRef.Flags & GC_CALL_INTERIOR)
{
stackRefs[i].i64ExtraData = GC_CALL_INTERIOR;
stackRefs[i].objHnd.SetDacTargetPtr(CLRDATA_ADDRESS_TO_TADDR(sosStackRef.Address));
stackRefs[i].pObject = CLRDATA_ADDRESS_TO_TADDR(sosStackRef.Object) | 1;
Copy link
Member

Choose a reason for hiding this comment

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

So i64ExtraData no longer needs to be set to GC_CALL_INTERIOR in this branch?

Copy link
Member

Choose a reason for hiding this comment

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

Or either branch?

Copy link
Contributor Author

@leculver leculver Mar 28, 2023

Choose a reason for hiding this comment

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

The original behavior was that i64ExtraData was always set to 0, for all kinds of stack pointers. (It probably should be set, but it's not.) Setting it to 0 in both cases just makes sure we preserve the previous behavior that VS might have taken a dependency on.

I'm solving this a different way in the upcoming change to improve performance. (That PR will come later, after VS takes a look at it.)

Copy link
Member

Choose a reason for hiding this comment

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

Sounds good.

@leculver leculver merged commit bd6ed47 into dotnet:main Mar 28, 2023
@leculver leculver deleted the stackEnumerationFix branch March 28, 2023 21:03
@ghost ghost locked as resolved and limited conversation to collaborators Apr 28, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants