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

GCHeap::NextObj fix #71113

Merged
merged 1 commit into from
Jun 22, 2022
Merged

GCHeap::NextObj fix #71113

merged 1 commit into from
Jun 22, 2022

Conversation

Maoni0
Copy link
Member

@Maoni0 Maoni0 commented Jun 22, 2022

this is to fix #70231.

for regions we could run into this situation -

object is the last object before heap_segment_allocated (hs)
T0 calls NextObj, gets next obj which starts at heap_segment_allocated (hs)
T1 changes ephemeral_heap_segment to hs
T0 does these comparisons

        (nextobj >= heap_segment_allocated(hs) && hs != hp->ephemeral_heap_segment) ||
        (nextobj >= hp->alloc_allocated))

both still false because alloc_allocated hasn't been changed just yet (and the old alloc_allocated is larger than nextobj)

T0 validates next obj, concludes its m_alignpad is not 0, asserts

T1 forms an allocation context starting at heap_segment_allocated, clears memory so by the time the dump is taken, m_alignpad is already cleared (actually we clear it in a_fit_segment_end)

I'm fixing this by saving the ephemeral_heap_segment and alloc_allocated and bail if nextobj is not on the saved eph seg or if those 2 saved values are no long in sync.

@ghost
Copy link

ghost commented Jun 22, 2022

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

Issue Details

for regions we could run into this situation -

object is the last object before heap_segment_allocated (hs)
T0 calls NextObj, gets next obj which starts at heap_segment_allocated (hs)
T1 changes ephemeral_heap_segment to hs
T0 does these comparisons

        (nextobj >= heap_segment_allocated(hs) && hs != hp->ephemeral_heap_segment) ||
        (nextobj >= hp->alloc_allocated))

both still false because alloc_allocated hasn't been changed just yet (and the old alloc_allocated is larger than nextobj)

T0 validates next obj, concludes its m_alignpad is not 0, asserts

T1 forms an allocation context starting at heap_segment_allocated, clears memory so by the time the dump is taken, m_alignpad is already cleared (actually we clear it in a_fit_segment_end)

I'm fixing this by saving the ephemeral_heap_segment and alloc_allocated and bail if nextobj is not on the saved eph seg or if those 2 saved values are no long in sync.

Author: Maoni0
Assignees: -
Labels:

area-GC-coreclr

Milestone: -

@Maoni0 Maoni0 merged commit 9616b57 into dotnet:main Jun 22, 2022
@ghost ghost locked as resolved and limited conversation to collaborators Jul 23, 2022
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.

Assert failure: m_alignpad == 0 in libraries tests
2 participants