This fixes Github issue 78206 - a heap corruption problem associated with mark stack overflow #78756
Conversation
…with mark stack overflow. Dumps provided by the customer showed in all cases that the min_overflow_address/max_overflow_address fields had values different from their initial values of MAX_PTR and 0. This implies that a mark stack overflow has occurred, but has not been properly handled. Looking at the code, we realized that we may still have objects in the mark prefetch queue as we enter process_mark_overflow. These objects may cause another mark stack overflow when they are traced. So we need to drain the mark prefetch queue before we check the min_overflow_address/max_overflow_address fields. We provided a private build of clrgc.dll to the customer reporting the issue, and customer has validated that the fix resolves the issue.
ghost
added
the
|
Tagging subscribers to this area: @dotnet/gc Issue DetailsDumps provided by the customer showed in all cases that the min_overflow_address/max_overflow_address fields had values different from their initial values of MAX_PTR and 0. This implies that a mark stack overflow has occurred, but has not been properly handled. Looking at the code, we realized that we may still have objects in the mark prefetch queue as we enter process_mark_overflow. These objects may cause another mark stack overflow when they are traced. So we need to drain the mark prefetch queue before we check the min_overflow_address/max_overflow_address fields. We provided a private build of clrgc.dll with this fix to the customer reporting the issue, and customer has validated that the fix resolves the issue.
|
|
oops, I forgot to mention that this means we should not have the |
|
Right, we have the invariant that the mark queue is empty after calling |
…ere the mark queue should be empty with asserts.
…_t::verify_empty instead of an assert testing the result from mark_queue_t::get_next_marked().
|
/backport to release/7.0 |
|
Started backporting to release/7.0: https://github.com/dotnet/runtime/actions/runs/3549509468 |
3 participants
Fixes #78206
Dumps provided by the customer showed in all cases that the min_overflow_address/max_overflow_address fields had values different from their initial values of MAX_PTR and 0. This implies that a mark stack overflow has occurred, but has not been properly handled.
Looking at the code, we realized that we may still have objects in the mark prefetch queue as we enter process_mark_overflow. These objects may cause another mark stack overflow when they are traced. So we need to drain the mark prefetch queue before we check the min_overflow_address/max_overflow_address fields.
We provided a private build of clrgc.dll with this fix to the customer reporting the issue, and customer has validated that the fix resolves the issue.