Skip to content

Conversation

AntonLapounov
Copy link
Member

The allocate_in_free code path in the allocate_in_expanded_heap function would incorrectly calculate the large (double) alignment padding size when limiting the plug size (SHORT_PLUGS) if set_padding_on_saved_p was true:

set_padding_in_expand (old_loc, set_padding_on_saved_p, pinned_plug_entry); // Sets the padding flag on the saved plug
...
pad += switch_alignment_size (is_plug_padded (old_loc)); // Reads the padding flag from the old (different!) plug

That caused access violation during a later heap walk since the g_gc_pFreeObjectMethodTable pointer marking the gap was not placed at the right address.

The allocate_in_free code path in allocate_in_expanded_heap incorrectly calculated the large (double) alignment padding size when limiting the plug size (SHORT_PLUGS) if set_padding_on_saved_p was true:

    set_padding_in_expand (old_loc, set_padding_on_saved_p, pinned_plug_entry); // Sets the padding flag on the saved plug
    ...
    pad += switch_alignment_size (is_plug_padded (old_loc)); // Reads the padding flag from the old (different!) plug

That caused access violation during a later heap walk since the g_gc_pFreeObjectMethodTable pointer marking the gap was not placed at the right address.
@AntonLapounov AntonLapounov merged commit 7c24ebc into dotnet:master Jan 8, 2020
@AntonLapounov AntonLapounov deleted the FixGCHeapCorruptionOnARM2 branch January 8, 2020 10:12
AntonLapounov added a commit to AntonLapounov/coreclr that referenced this pull request Jan 10, 2020
Anipik pushed a commit to dotnet/coreclr that referenced this pull request Feb 13, 2020
@ghost ghost locked as resolved and limited conversation to collaborators Dec 11, 2020
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