[release/7.0] This fixes Github issue 78206 - a heap corruption problem associated with mark stack overflow #78855
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.
…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().
|
Tagging subscribers to this area: @dotnet/gc Issue DetailsBackport of #78756 to release/7.0 /cc @mangod9 @PeterSolMS Customer ImpactTestingRiskIMPORTANT: Is this backport for a servicing release? If so and this change touches code that ships in a NuGet package, please make certain that you have added any necessary package authoring and gotten it explicitly reviewed.
|
|
Please fill out the template. Request approval from Jeff Schwartz. If approved, add the Friendly reminder that the window for merging backports this month is only going to be of one day (29th-30th) so I want to make sure everything is ready for me to just press "merge" when the branch opens. |
|
Branding has been done. Milestone is 7.0.2. Signed-off by area owners. Approved by Tactics. No OOB package authoring changes needed. CI is green. |
Backport of #78756 to release/7.0
/cc @mangod9 @PeterSolMS
Customer Impact
In rare cases, mark stack overflow causes heap corruption, and thus access violations or other kinds of crashes.
Testing
Customer verified fix, we could not reproduce the issue locally.
Risk
Risk is low, because adding a call to drain_mark_queue can not cause problems. The places where a call to drain_mark_queue was replaced by a check (in debug) that the mark queue is empty were verified by code inspection.
IMPORTANT: Is this backport for a servicing release? If so and this change touches code that ships in a NuGet package, please make certain that you have added any necessary package authoring and gotten it explicitly reviewed.