This fixes Github issue 78206 - a heap corruption problem associated with mark stack overflow by PeterSolMS · Pull Request #78756 · dotnet/runtime

PeterSolMS · 2022-11-23T09:49:06Z

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.

…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 · 2022-11-23T09:49:25Z

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

Issue Details

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.

Author:	PeterSolMS
Assignees:	PeterSolMS
Labels:	`area-GC-coreclr`
Milestone:	-

mangod9

Thanks for working on this. Assume we will port this to 7?

Maoni0 · 2022-11-24T00:39:43Z

oops, I forgot to mention that this means we should not have the drain_mark_queue call after scan_dependent_handles because we are guaranteed to call process_mark_overflow which will guarantee to run drain_mark_queue.

PeterSolMS · 2022-11-24T09:54:40Z

Right, we have the invariant that the mark queue is empty after calling process_mark_overflow, and because of the logic inside both flavors of scan_dependent_handles, also after calling scan_dependent_handles. Thus the calls to drain_mark_queue right after calls to scan_dependent_handles can be eliminated, as well as one call to drain_mark_queue inside the WKS flavor of scan_dependent_handles.

…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().

mangod9 · 2022-11-25T16:39:47Z

/backport to release/7.0

github-actions · 2022-11-25T16:40:02Z

Started backporting to release/7.0: https://github.com/dotnet/runtime/actions/runs/3549509468

PeterSolMS · 2022-11-23T09:49:06Z

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.

…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 · 2022-11-23T09:49:25Z

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

Issue Details

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.

Author:	PeterSolMS
Assignees:	PeterSolMS
Labels:	`area-GC-coreclr`
Milestone:	-

mangod9

Thanks for working on this. Assume we will port this to 7?

Maoni0 · 2022-11-24T00:39:43Z

oops, I forgot to mention that this means we should not have the drain_mark_queue call after scan_dependent_handles because we are guaranteed to call process_mark_overflow which will guarantee to run drain_mark_queue.

PeterSolMS · 2022-11-24T09:54:40Z

Right, we have the invariant that the mark queue is empty after calling process_mark_overflow, and because of the logic inside both flavors of scan_dependent_handles, also after calling scan_dependent_handles. Thus the calls to drain_mark_queue right after calls to scan_dependent_handles can be eliminated, as well as one call to drain_mark_queue inside the WKS flavor of scan_dependent_handles.

…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().

mangod9 · 2022-11-25T16:39:47Z

/backport to release/7.0

github-actions · 2022-11-25T16:40:02Z

Started backporting to release/7.0: https://github.com/dotnet/runtime/actions/runs/3549509468

PeterSolMS · 2022-11-23T09:49:06Z

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.

…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 · 2022-11-23T09:49:25Z

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

Issue Details

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.

Author:	PeterSolMS
Assignees:	PeterSolMS
Labels:	`area-GC-coreclr`
Milestone:	-

mangod9

Thanks for working on this. Assume we will port this to 7?

Maoni0 · 2022-11-24T00:39:43Z

oops, I forgot to mention that this means we should not have the drain_mark_queue call after scan_dependent_handles because we are guaranteed to call process_mark_overflow which will guarantee to run drain_mark_queue.

PeterSolMS · 2022-11-24T09:54:40Z

Right, we have the invariant that the mark queue is empty after calling process_mark_overflow, and because of the logic inside both flavors of scan_dependent_handles, also after calling scan_dependent_handles. Thus the calls to drain_mark_queue right after calls to scan_dependent_handles can be eliminated, as well as one call to drain_mark_queue inside the WKS flavor of scan_dependent_handles.

…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().

mangod9 · 2022-11-25T16:39:47Z

/backport to release/7.0

github-actions · 2022-11-25T16:40:02Z

Started backporting to release/7.0: https://github.com/dotnet/runtime/actions/runs/3549509468

PeterSolMS · 2022-11-23T09:49:06Z

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.

…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 · 2022-11-23T09:49:25Z

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

Issue Details

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.

Author:	PeterSolMS
Assignees:	PeterSolMS
Labels:	`area-GC-coreclr`
Milestone:	-

mangod9

Thanks for working on this. Assume we will port this to 7?

Maoni0 · 2022-11-24T00:39:43Z

oops, I forgot to mention that this means we should not have the drain_mark_queue call after scan_dependent_handles because we are guaranteed to call process_mark_overflow which will guarantee to run drain_mark_queue.

PeterSolMS · 2022-11-24T09:54:40Z

Right, we have the invariant that the mark queue is empty after calling process_mark_overflow, and because of the logic inside both flavors of scan_dependent_handles, also after calling scan_dependent_handles. Thus the calls to drain_mark_queue right after calls to scan_dependent_handles can be eliminated, as well as one call to drain_mark_queue inside the WKS flavor of scan_dependent_handles.

…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().

mangod9 · 2022-11-25T16:39:47Z

/backport to release/7.0

github-actions · 2022-11-25T16:40:02Z

Started backporting to release/7.0: https://github.com/dotnet/runtime/actions/runs/3549509468

PeterSolMS · 2022-11-23T09:49:06Z

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.

…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 · 2022-11-23T09:49:25Z

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

Issue Details

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.

Author:	PeterSolMS
Assignees:	PeterSolMS
Labels:	`area-GC-coreclr`
Milestone:	-

mangod9

Thanks for working on this. Assume we will port this to 7?

Maoni0 · 2022-11-24T00:39:43Z

oops, I forgot to mention that this means we should not have the drain_mark_queue call after scan_dependent_handles because we are guaranteed to call process_mark_overflow which will guarantee to run drain_mark_queue.

PeterSolMS · 2022-11-24T09:54:40Z

Right, we have the invariant that the mark queue is empty after calling process_mark_overflow, and because of the logic inside both flavors of scan_dependent_handles, also after calling scan_dependent_handles. Thus the calls to drain_mark_queue right after calls to scan_dependent_handles can be eliminated, as well as one call to drain_mark_queue inside the WKS flavor of scan_dependent_handles.

…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().

mangod9 · 2022-11-25T16:39:47Z

/backport to release/7.0

github-actions · 2022-11-25T16:40:02Z

Started backporting to release/7.0: https://github.com/dotnet/runtime/actions/runs/3549509468

PeterSolMS · 2022-11-23T09:49:06Z

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.

…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 · 2022-11-23T09:49:25Z

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

Issue Details

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.

Author:	PeterSolMS
Assignees:	PeterSolMS
Labels:	`area-GC-coreclr`
Milestone:	-

mangod9

Thanks for working on this. Assume we will port this to 7?

Maoni0 · 2022-11-24T00:39:43Z

oops, I forgot to mention that this means we should not have the drain_mark_queue call after scan_dependent_handles because we are guaranteed to call process_mark_overflow which will guarantee to run drain_mark_queue.

PeterSolMS · 2022-11-24T09:54:40Z

Right, we have the invariant that the mark queue is empty after calling process_mark_overflow, and because of the logic inside both flavors of scan_dependent_handles, also after calling scan_dependent_handles. Thus the calls to drain_mark_queue right after calls to scan_dependent_handles can be eliminated, as well as one call to drain_mark_queue inside the WKS flavor of scan_dependent_handles.

…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().

mangod9 · 2022-11-25T16:39:47Z

/backport to release/7.0

github-actions · 2022-11-25T16:40:02Z

Started backporting to release/7.0: https://github.com/dotnet/runtime/actions/runs/3549509468

PeterSolMS · 2022-11-23T09:49:06Z

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.

…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 · 2022-11-23T09:49:25Z

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

Issue Details

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.

Author:	PeterSolMS
Assignees:	PeterSolMS
Labels:	`area-GC-coreclr`
Milestone:	-

mangod9

Thanks for working on this. Assume we will port this to 7?

Maoni0 · 2022-11-24T00:39:43Z

oops, I forgot to mention that this means we should not have the drain_mark_queue call after scan_dependent_handles because we are guaranteed to call process_mark_overflow which will guarantee to run drain_mark_queue.

PeterSolMS · 2022-11-24T09:54:40Z

Right, we have the invariant that the mark queue is empty after calling process_mark_overflow, and because of the logic inside both flavors of scan_dependent_handles, also after calling scan_dependent_handles. Thus the calls to drain_mark_queue right after calls to scan_dependent_handles can be eliminated, as well as one call to drain_mark_queue inside the WKS flavor of scan_dependent_handles.

…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().

mangod9 · 2022-11-25T16:39:47Z

/backport to release/7.0

github-actions · 2022-11-25T16:40:02Z

Started backporting to release/7.0: https://github.com/dotnet/runtime/actions/runs/3549509468

PeterSolMS · 2022-11-23T09:49:06Z

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.

…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 · 2022-11-23T09:49:25Z

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

Issue Details

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.

Author:	PeterSolMS
Assignees:	PeterSolMS
Labels:	`area-GC-coreclr`
Milestone:	-

mangod9

Thanks for working on this. Assume we will port this to 7?

Maoni0 · 2022-11-24T00:39:43Z

oops, I forgot to mention that this means we should not have the drain_mark_queue call after scan_dependent_handles because we are guaranteed to call process_mark_overflow which will guarantee to run drain_mark_queue.

PeterSolMS · 2022-11-24T09:54:40Z

Right, we have the invariant that the mark queue is empty after calling process_mark_overflow, and because of the logic inside both flavors of scan_dependent_handles, also after calling scan_dependent_handles. Thus the calls to drain_mark_queue right after calls to scan_dependent_handles can be eliminated, as well as one call to drain_mark_queue inside the WKS flavor of scan_dependent_handles.

…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().

mangod9 · 2022-11-25T16:39:47Z

/backport to release/7.0

github-actions · 2022-11-25T16:40:02Z

Started backporting to release/7.0: https://github.com/dotnet/runtime/actions/runs/3549509468

PeterSolMS requested review from Maoni0, cshung, mangod9 and mrsharm November 23, 2022 09:49

ghost added the area-GC-coreclr label Nov 23, 2022

ghost assigned PeterSolMS Nov 23, 2022

mangod9 reviewed Nov 23, 2022
View reviewed changes

mangod9 approved these changes Nov 23, 2022
View reviewed changes

PeterSolMS added 2 commits November 24, 2022 11:16

Adressed code review feedback - replaced calls to drain_mark_queue wh…
d864716
…ere the mark queue should be empty with asserts.

Make code slightly more explicit by using exisiting method mark_queue…
7387059
…_t::verify_empty instead of an assert testing the result from mark_queue_t::get_next_marked().

andrewb3010 mentioned this pull request Nov 24, 2022
Fatal error. Internal CLR error. (0x80131506) in .Net 7 #78206
Closed

PeterSolMS merged commit 4832236 into dotnet:mainNov 25, 2022

github-actionsBot mentioned this pull request Nov 25, 2022
[release/7.0] This fixes Github issue 78206 - a heap corruption problem associated with mark stack overflow #78855
Merged

EgorBo mentioned this pull request Nov 28, 2022
Test failure GC\\Regressions\\Github\\Runtime_76219\\Runtime_76219\\Runtime_76219.cmd #78899
Closed

ghost locked as resolved and limited conversation to collaborators Dec 25, 2022