[mono][sgen] Fix card scanning in LOS non-array objects by BrzVlad · Pull Request #125116 · dotnet/runtime

BrzVlad · 2026-03-03T13:43:09Z

sgen_card_table_region_begin_scanning needs to determine whether any cards are marked in the object starting at start address. The current card size in 512 bytes. Consider an object with start 500 and size 20, so this object lives within 2 cards. We will check the card associated with the address 500. Once this iteration is done, we will check whether start + card_size < end => 500 + 512 < 520. This is false, so we will no longer scan the second card. The algorithm was expecting the start address to be aligned to the card start, which is what the fix does.

This bug is severe, but, in practice, this code path is not as frequent. This bug would only affect objects greater than 8k, that are not arrays.

Fixes#124941

`sgen_card_table_region_begin_scanning` needs to determine whether any cards are marked in the object starting at `start` address. The current card size in 512 bytes. Consider an object with start 500 and size 20, so this object lives within 2 cards. We will check the card associated with the address 500. Once this iteration is done, we will check whether `start + card_size < end` => `500 + 512 < 520`. This is false, so we will no longer scan the second card. The algorithm was expecting the start address to be aligned to the card start, which is what the fix does. This bug is severe, but, in practice, this code path is not as frequent. This bug would only affect objects greater than 8k, that are not arrays.

dotnet-policy-service · 2026-03-03T13:44:09Z

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

Copilot

Pull request overview

Fixes SGen card-table scanning for large (LOS) non-array objects when the object start address is not aligned to a card boundary, ensuring all cards that overlap the object are checked for marks before deciding whether to scan the object.

Changes:

Align the start address down to the containing card boundary in sgen_card_table_region_begin_scanning (overlapping-cards configuration).
Ensures multi-card objects that begin mid-card do not skip subsequent cards during the per-card iteration.

lateralusX

LGTM!

BrzVlad · 2026-03-05T11:20:13Z

/backport to release/9.0-staging

BrzVlad · 2026-03-05T11:20:21Z

/backport to release/10.0

github-actions · 2026-03-05T11:20:27Z

Started backporting to release/9.0-staging (link to workflow run)

github-actions · 2026-03-05T11:20:35Z

Started backporting to release/10.0 (link to workflow run)

@BrzVlad

… objects (#125212) Backport of #125116 to release/9.0-staging /cc @BrzVlad ## Customer Impact - [x] Customer reported - [ ] Found internally In some cases, cards marked for non-array LOS objects (objects with size greater than 8K) were being ignored. This means that the GC could fail to observe that some object refs were stored inside these large objects. This can result in GC crashes or other undefined behavior. This can impact all mono workloads. This issue was confirmed to be hit by a customer who also investigated it via a GC debug flag. There are other undiagnosed GC crashes that might hopefully be fixed by this. ## Regression - [ ] Yes - [x] No ## Testing Was able to create a console app reproducing this bug. Validated the fix. ## Risk Low. The fix just does an address alignment, in order to scan correctly an additional card. Co-authored-by: Vlad Brezae <brezaevlad@gmail.com>

#125213) Backport of #125116 to release/10.0 ## Customer Impact - [x] Customer reported - [ ] Found internally In some cases, cards marked for non-array LOS objects (objects with size greater than 8K) were being ignored. This means that the GC could fail to observe that some object refs were stored inside these large objects. This can result in GC crashes or other undefined behavior. This can impact all mono workloads. This issue was confirmed to be hit by a customer who also investigated it via a GC debug flag. There are other undiagnosed GC crashes that might hopefully be fixed by this. ## Regression - [ ] Yes - [x] No ## Testing Was able to create a console app reproducing this bug. Validated the fix. ## Risk Low. The fix just does an address alignment, in order to scan correctly an additional card. Co-authored-by: Vlad Brezae <brezaevlad@gmail.com>

BrzVlad · 2026-03-03T13:43:09Z

sgen_card_table_region_begin_scanning needs to determine whether any cards are marked in the object starting at start address. The current card size in 512 bytes. Consider an object with start 500 and size 20, so this object lives within 2 cards. We will check the card associated with the address 500. Once this iteration is done, we will check whether start + card_size < end => 500 + 512 < 520. This is false, so we will no longer scan the second card. The algorithm was expecting the start address to be aligned to the card start, which is what the fix does.

This bug is severe, but, in practice, this code path is not as frequent. This bug would only affect objects greater than 8k, that are not arrays.

Fixes#124941

`sgen_card_table_region_begin_scanning` needs to determine whether any cards are marked in the object starting at `start` address. The current card size in 512 bytes. Consider an object with start 500 and size 20, so this object lives within 2 cards. We will check the card associated with the address 500. Once this iteration is done, we will check whether `start + card_size < end` => `500 + 512 < 520`. This is false, so we will no longer scan the second card. The algorithm was expecting the start address to be aligned to the card start, which is what the fix does. This bug is severe, but, in practice, this code path is not as frequent. This bug would only affect objects greater than 8k, that are not arrays.

dotnet-policy-service · 2026-03-03T13:44:09Z

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

Copilot

Pull request overview

Fixes SGen card-table scanning for large (LOS) non-array objects when the object start address is not aligned to a card boundary, ensuring all cards that overlap the object are checked for marks before deciding whether to scan the object.

Changes:

Align the start address down to the containing card boundary in sgen_card_table_region_begin_scanning (overlapping-cards configuration).
Ensures multi-card objects that begin mid-card do not skip subsequent cards during the per-card iteration.

lateralusX

LGTM!

BrzVlad · 2026-03-05T11:20:13Z

/backport to release/9.0-staging

BrzVlad · 2026-03-05T11:20:21Z

/backport to release/10.0

github-actions · 2026-03-05T11:20:27Z

Started backporting to release/9.0-staging (link to workflow run)

github-actions · 2026-03-05T11:20:35Z

Started backporting to release/10.0 (link to workflow run)

@BrzVlad

… objects (#125212) Backport of #125116 to release/9.0-staging /cc @BrzVlad ## Customer Impact - [x] Customer reported - [ ] Found internally In some cases, cards marked for non-array LOS objects (objects with size greater than 8K) were being ignored. This means that the GC could fail to observe that some object refs were stored inside these large objects. This can result in GC crashes or other undefined behavior. This can impact all mono workloads. This issue was confirmed to be hit by a customer who also investigated it via a GC debug flag. There are other undiagnosed GC crashes that might hopefully be fixed by this. ## Regression - [ ] Yes - [x] No ## Testing Was able to create a console app reproducing this bug. Validated the fix. ## Risk Low. The fix just does an address alignment, in order to scan correctly an additional card. Co-authored-by: Vlad Brezae <brezaevlad@gmail.com>

#125213) Backport of #125116 to release/10.0 ## Customer Impact - [x] Customer reported - [ ] Found internally In some cases, cards marked for non-array LOS objects (objects with size greater than 8K) were being ignored. This means that the GC could fail to observe that some object refs were stored inside these large objects. This can result in GC crashes or other undefined behavior. This can impact all mono workloads. This issue was confirmed to be hit by a customer who also investigated it via a GC debug flag. There are other undiagnosed GC crashes that might hopefully be fixed by this. ## Regression - [ ] Yes - [x] No ## Testing Was able to create a console app reproducing this bug. Validated the fix. ## Risk Low. The fix just does an address alignment, in order to scan correctly an additional card. Co-authored-by: Vlad Brezae <brezaevlad@gmail.com>

BrzVlad · 2026-03-03T13:43:09Z

sgen_card_table_region_begin_scanning needs to determine whether any cards are marked in the object starting at start address. The current card size in 512 bytes. Consider an object with start 500 and size 20, so this object lives within 2 cards. We will check the card associated with the address 500. Once this iteration is done, we will check whether start + card_size < end => 500 + 512 < 520. This is false, so we will no longer scan the second card. The algorithm was expecting the start address to be aligned to the card start, which is what the fix does.

This bug is severe, but, in practice, this code path is not as frequent. This bug would only affect objects greater than 8k, that are not arrays.

Fixes#124941

`sgen_card_table_region_begin_scanning` needs to determine whether any cards are marked in the object starting at `start` address. The current card size in 512 bytes. Consider an object with start 500 and size 20, so this object lives within 2 cards. We will check the card associated with the address 500. Once this iteration is done, we will check whether `start + card_size < end` => `500 + 512 < 520`. This is false, so we will no longer scan the second card. The algorithm was expecting the start address to be aligned to the card start, which is what the fix does. This bug is severe, but, in practice, this code path is not as frequent. This bug would only affect objects greater than 8k, that are not arrays.

dotnet-policy-service · 2026-03-03T13:44:09Z

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

Copilot

Pull request overview

Fixes SGen card-table scanning for large (LOS) non-array objects when the object start address is not aligned to a card boundary, ensuring all cards that overlap the object are checked for marks before deciding whether to scan the object.

Changes:

Align the start address down to the containing card boundary in sgen_card_table_region_begin_scanning (overlapping-cards configuration).
Ensures multi-card objects that begin mid-card do not skip subsequent cards during the per-card iteration.

lateralusX

LGTM!

BrzVlad · 2026-03-05T11:20:13Z

/backport to release/9.0-staging

BrzVlad · 2026-03-05T11:20:21Z

/backport to release/10.0

github-actions · 2026-03-05T11:20:27Z

Started backporting to release/9.0-staging (link to workflow run)

github-actions · 2026-03-05T11:20:35Z

Started backporting to release/10.0 (link to workflow run)

@BrzVlad

… objects (#125212) Backport of #125116 to release/9.0-staging /cc @BrzVlad ## Customer Impact - [x] Customer reported - [ ] Found internally In some cases, cards marked for non-array LOS objects (objects with size greater than 8K) were being ignored. This means that the GC could fail to observe that some object refs were stored inside these large objects. This can result in GC crashes or other undefined behavior. This can impact all mono workloads. This issue was confirmed to be hit by a customer who also investigated it via a GC debug flag. There are other undiagnosed GC crashes that might hopefully be fixed by this. ## Regression - [ ] Yes - [x] No ## Testing Was able to create a console app reproducing this bug. Validated the fix. ## Risk Low. The fix just does an address alignment, in order to scan correctly an additional card. Co-authored-by: Vlad Brezae <brezaevlad@gmail.com>

#125213) Backport of #125116 to release/10.0 ## Customer Impact - [x] Customer reported - [ ] Found internally In some cases, cards marked for non-array LOS objects (objects with size greater than 8K) were being ignored. This means that the GC could fail to observe that some object refs were stored inside these large objects. This can result in GC crashes or other undefined behavior. This can impact all mono workloads. This issue was confirmed to be hit by a customer who also investigated it via a GC debug flag. There are other undiagnosed GC crashes that might hopefully be fixed by this. ## Regression - [ ] Yes - [x] No ## Testing Was able to create a console app reproducing this bug. Validated the fix. ## Risk Low. The fix just does an address alignment, in order to scan correctly an additional card. Co-authored-by: Vlad Brezae <brezaevlad@gmail.com>

BrzVlad · 2026-03-03T13:43:09Z

sgen_card_table_region_begin_scanning needs to determine whether any cards are marked in the object starting at start address. The current card size in 512 bytes. Consider an object with start 500 and size 20, so this object lives within 2 cards. We will check the card associated with the address 500. Once this iteration is done, we will check whether start + card_size < end => 500 + 512 < 520. This is false, so we will no longer scan the second card. The algorithm was expecting the start address to be aligned to the card start, which is what the fix does.

This bug is severe, but, in practice, this code path is not as frequent. This bug would only affect objects greater than 8k, that are not arrays.

Fixes#124941

`sgen_card_table_region_begin_scanning` needs to determine whether any cards are marked in the object starting at `start` address. The current card size in 512 bytes. Consider an object with start 500 and size 20, so this object lives within 2 cards. We will check the card associated with the address 500. Once this iteration is done, we will check whether `start + card_size < end` => `500 + 512 < 520`. This is false, so we will no longer scan the second card. The algorithm was expecting the start address to be aligned to the card start, which is what the fix does. This bug is severe, but, in practice, this code path is not as frequent. This bug would only affect objects greater than 8k, that are not arrays.

dotnet-policy-service · 2026-03-03T13:44:09Z

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

Copilot

Pull request overview

Fixes SGen card-table scanning for large (LOS) non-array objects when the object start address is not aligned to a card boundary, ensuring all cards that overlap the object are checked for marks before deciding whether to scan the object.

Changes:

Align the start address down to the containing card boundary in sgen_card_table_region_begin_scanning (overlapping-cards configuration).
Ensures multi-card objects that begin mid-card do not skip subsequent cards during the per-card iteration.

lateralusX

LGTM!

BrzVlad · 2026-03-05T11:20:13Z

/backport to release/9.0-staging

BrzVlad · 2026-03-05T11:20:21Z

/backport to release/10.0

github-actions · 2026-03-05T11:20:27Z

Started backporting to release/9.0-staging (link to workflow run)

github-actions · 2026-03-05T11:20:35Z

Started backporting to release/10.0 (link to workflow run)

@BrzVlad

… objects (#125212) Backport of #125116 to release/9.0-staging /cc @BrzVlad ## Customer Impact - [x] Customer reported - [ ] Found internally In some cases, cards marked for non-array LOS objects (objects with size greater than 8K) were being ignored. This means that the GC could fail to observe that some object refs were stored inside these large objects. This can result in GC crashes or other undefined behavior. This can impact all mono workloads. This issue was confirmed to be hit by a customer who also investigated it via a GC debug flag. There are other undiagnosed GC crashes that might hopefully be fixed by this. ## Regression - [ ] Yes - [x] No ## Testing Was able to create a console app reproducing this bug. Validated the fix. ## Risk Low. The fix just does an address alignment, in order to scan correctly an additional card. Co-authored-by: Vlad Brezae <brezaevlad@gmail.com>

#125213) Backport of #125116 to release/10.0 ## Customer Impact - [x] Customer reported - [ ] Found internally In some cases, cards marked for non-array LOS objects (objects with size greater than 8K) were being ignored. This means that the GC could fail to observe that some object refs were stored inside these large objects. This can result in GC crashes or other undefined behavior. This can impact all mono workloads. This issue was confirmed to be hit by a customer who also investigated it via a GC debug flag. There are other undiagnosed GC crashes that might hopefully be fixed by this. ## Regression - [ ] Yes - [x] No ## Testing Was able to create a console app reproducing this bug. Validated the fix. ## Risk Low. The fix just does an address alignment, in order to scan correctly an additional card. Co-authored-by: Vlad Brezae <brezaevlad@gmail.com>

BrzVlad · 2026-03-03T13:43:09Z

sgen_card_table_region_begin_scanning needs to determine whether any cards are marked in the object starting at start address. The current card size in 512 bytes. Consider an object with start 500 and size 20, so this object lives within 2 cards. We will check the card associated with the address 500. Once this iteration is done, we will check whether start + card_size < end => 500 + 512 < 520. This is false, so we will no longer scan the second card. The algorithm was expecting the start address to be aligned to the card start, which is what the fix does.

This bug is severe, but, in practice, this code path is not as frequent. This bug would only affect objects greater than 8k, that are not arrays.

Fixes#124941

`sgen_card_table_region_begin_scanning` needs to determine whether any cards are marked in the object starting at `start` address. The current card size in 512 bytes. Consider an object with start 500 and size 20, so this object lives within 2 cards. We will check the card associated with the address 500. Once this iteration is done, we will check whether `start + card_size < end` => `500 + 512 < 520`. This is false, so we will no longer scan the second card. The algorithm was expecting the start address to be aligned to the card start, which is what the fix does. This bug is severe, but, in practice, this code path is not as frequent. This bug would only affect objects greater than 8k, that are not arrays.

dotnet-policy-service · 2026-03-03T13:44:09Z

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

Copilot

Pull request overview

Fixes SGen card-table scanning for large (LOS) non-array objects when the object start address is not aligned to a card boundary, ensuring all cards that overlap the object are checked for marks before deciding whether to scan the object.

Changes:

Align the start address down to the containing card boundary in sgen_card_table_region_begin_scanning (overlapping-cards configuration).
Ensures multi-card objects that begin mid-card do not skip subsequent cards during the per-card iteration.

lateralusX

LGTM!

BrzVlad · 2026-03-05T11:20:13Z

/backport to release/9.0-staging

BrzVlad · 2026-03-05T11:20:21Z

/backport to release/10.0

github-actions · 2026-03-05T11:20:27Z

Started backporting to release/9.0-staging (link to workflow run)

github-actions · 2026-03-05T11:20:35Z

Started backporting to release/10.0 (link to workflow run)

@BrzVlad

… objects (#125212) Backport of #125116 to release/9.0-staging /cc @BrzVlad ## Customer Impact - [x] Customer reported - [ ] Found internally In some cases, cards marked for non-array LOS objects (objects with size greater than 8K) were being ignored. This means that the GC could fail to observe that some object refs were stored inside these large objects. This can result in GC crashes or other undefined behavior. This can impact all mono workloads. This issue was confirmed to be hit by a customer who also investigated it via a GC debug flag. There are other undiagnosed GC crashes that might hopefully be fixed by this. ## Regression - [ ] Yes - [x] No ## Testing Was able to create a console app reproducing this bug. Validated the fix. ## Risk Low. The fix just does an address alignment, in order to scan correctly an additional card. Co-authored-by: Vlad Brezae <brezaevlad@gmail.com>

#125213) Backport of #125116 to release/10.0 ## Customer Impact - [x] Customer reported - [ ] Found internally In some cases, cards marked for non-array LOS objects (objects with size greater than 8K) were being ignored. This means that the GC could fail to observe that some object refs were stored inside these large objects. This can result in GC crashes or other undefined behavior. This can impact all mono workloads. This issue was confirmed to be hit by a customer who also investigated it via a GC debug flag. There are other undiagnosed GC crashes that might hopefully be fixed by this. ## Regression - [ ] Yes - [x] No ## Testing Was able to create a console app reproducing this bug. Validated the fix. ## Risk Low. The fix just does an address alignment, in order to scan correctly an additional card. Co-authored-by: Vlad Brezae <brezaevlad@gmail.com>

BrzVlad · 2026-03-03T13:43:09Z

sgen_card_table_region_begin_scanning needs to determine whether any cards are marked in the object starting at start address. The current card size in 512 bytes. Consider an object with start 500 and size 20, so this object lives within 2 cards. We will check the card associated with the address 500. Once this iteration is done, we will check whether start + card_size < end => 500 + 512 < 520. This is false, so we will no longer scan the second card. The algorithm was expecting the start address to be aligned to the card start, which is what the fix does.

This bug is severe, but, in practice, this code path is not as frequent. This bug would only affect objects greater than 8k, that are not arrays.

Fixes#124941

`sgen_card_table_region_begin_scanning` needs to determine whether any cards are marked in the object starting at `start` address. The current card size in 512 bytes. Consider an object with start 500 and size 20, so this object lives within 2 cards. We will check the card associated with the address 500. Once this iteration is done, we will check whether `start + card_size < end` => `500 + 512 < 520`. This is false, so we will no longer scan the second card. The algorithm was expecting the start address to be aligned to the card start, which is what the fix does. This bug is severe, but, in practice, this code path is not as frequent. This bug would only affect objects greater than 8k, that are not arrays.

dotnet-policy-service · 2026-03-03T13:44:09Z

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

Copilot

Pull request overview

Fixes SGen card-table scanning for large (LOS) non-array objects when the object start address is not aligned to a card boundary, ensuring all cards that overlap the object are checked for marks before deciding whether to scan the object.

Changes:

Align the start address down to the containing card boundary in sgen_card_table_region_begin_scanning (overlapping-cards configuration).
Ensures multi-card objects that begin mid-card do not skip subsequent cards during the per-card iteration.

lateralusX

LGTM!

BrzVlad · 2026-03-05T11:20:13Z

/backport to release/9.0-staging

BrzVlad · 2026-03-05T11:20:21Z

/backport to release/10.0

github-actions · 2026-03-05T11:20:27Z

Started backporting to release/9.0-staging (link to workflow run)

github-actions · 2026-03-05T11:20:35Z

Started backporting to release/10.0 (link to workflow run)

@BrzVlad

… objects (#125212) Backport of #125116 to release/9.0-staging /cc @BrzVlad ## Customer Impact - [x] Customer reported - [ ] Found internally In some cases, cards marked for non-array LOS objects (objects with size greater than 8K) were being ignored. This means that the GC could fail to observe that some object refs were stored inside these large objects. This can result in GC crashes or other undefined behavior. This can impact all mono workloads. This issue was confirmed to be hit by a customer who also investigated it via a GC debug flag. There are other undiagnosed GC crashes that might hopefully be fixed by this. ## Regression - [ ] Yes - [x] No ## Testing Was able to create a console app reproducing this bug. Validated the fix. ## Risk Low. The fix just does an address alignment, in order to scan correctly an additional card. Co-authored-by: Vlad Brezae <brezaevlad@gmail.com>

#125213) Backport of #125116 to release/10.0 ## Customer Impact - [x] Customer reported - [ ] Found internally In some cases, cards marked for non-array LOS objects (objects with size greater than 8K) were being ignored. This means that the GC could fail to observe that some object refs were stored inside these large objects. This can result in GC crashes or other undefined behavior. This can impact all mono workloads. This issue was confirmed to be hit by a customer who also investigated it via a GC debug flag. There are other undiagnosed GC crashes that might hopefully be fixed by this. ## Regression - [ ] Yes - [x] No ## Testing Was able to create a console app reproducing this bug. Validated the fix. ## Risk Low. The fix just does an address alignment, in order to scan correctly an additional card. Co-authored-by: Vlad Brezae <brezaevlad@gmail.com>

BrzVlad · 2026-03-03T13:43:09Z

sgen_card_table_region_begin_scanning needs to determine whether any cards are marked in the object starting at start address. The current card size in 512 bytes. Consider an object with start 500 and size 20, so this object lives within 2 cards. We will check the card associated with the address 500. Once this iteration is done, we will check whether start + card_size < end => 500 + 512 < 520. This is false, so we will no longer scan the second card. The algorithm was expecting the start address to be aligned to the card start, which is what the fix does.

This bug is severe, but, in practice, this code path is not as frequent. This bug would only affect objects greater than 8k, that are not arrays.

Fixes#124941

`sgen_card_table_region_begin_scanning` needs to determine whether any cards are marked in the object starting at `start` address. The current card size in 512 bytes. Consider an object with start 500 and size 20, so this object lives within 2 cards. We will check the card associated with the address 500. Once this iteration is done, we will check whether `start + card_size < end` => `500 + 512 < 520`. This is false, so we will no longer scan the second card. The algorithm was expecting the start address to be aligned to the card start, which is what the fix does. This bug is severe, but, in practice, this code path is not as frequent. This bug would only affect objects greater than 8k, that are not arrays.

dotnet-policy-service · 2026-03-03T13:44:09Z

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

Copilot

Pull request overview

Fixes SGen card-table scanning for large (LOS) non-array objects when the object start address is not aligned to a card boundary, ensuring all cards that overlap the object are checked for marks before deciding whether to scan the object.

Changes:

Align the start address down to the containing card boundary in sgen_card_table_region_begin_scanning (overlapping-cards configuration).
Ensures multi-card objects that begin mid-card do not skip subsequent cards during the per-card iteration.

lateralusX

LGTM!

BrzVlad · 2026-03-05T11:20:13Z

/backport to release/9.0-staging

BrzVlad · 2026-03-05T11:20:21Z

/backport to release/10.0

github-actions · 2026-03-05T11:20:27Z

Started backporting to release/9.0-staging (link to workflow run)

github-actions · 2026-03-05T11:20:35Z

Started backporting to release/10.0 (link to workflow run)

@BrzVlad

… objects (#125212) Backport of #125116 to release/9.0-staging /cc @BrzVlad ## Customer Impact - [x] Customer reported - [ ] Found internally In some cases, cards marked for non-array LOS objects (objects with size greater than 8K) were being ignored. This means that the GC could fail to observe that some object refs were stored inside these large objects. This can result in GC crashes or other undefined behavior. This can impact all mono workloads. This issue was confirmed to be hit by a customer who also investigated it via a GC debug flag. There are other undiagnosed GC crashes that might hopefully be fixed by this. ## Regression - [ ] Yes - [x] No ## Testing Was able to create a console app reproducing this bug. Validated the fix. ## Risk Low. The fix just does an address alignment, in order to scan correctly an additional card. Co-authored-by: Vlad Brezae <brezaevlad@gmail.com>

#125213) Backport of #125116 to release/10.0 ## Customer Impact - [x] Customer reported - [ ] Found internally In some cases, cards marked for non-array LOS objects (objects with size greater than 8K) were being ignored. This means that the GC could fail to observe that some object refs were stored inside these large objects. This can result in GC crashes or other undefined behavior. This can impact all mono workloads. This issue was confirmed to be hit by a customer who also investigated it via a GC debug flag. There are other undiagnosed GC crashes that might hopefully be fixed by this. ## Regression - [ ] Yes - [x] No ## Testing Was able to create a console app reproducing this bug. Validated the fix. ## Risk Low. The fix just does an address alignment, in order to scan correctly an additional card. Co-authored-by: Vlad Brezae <brezaevlad@gmail.com>

BrzVlad · 2026-03-03T13:43:09Z

sgen_card_table_region_begin_scanning needs to determine whether any cards are marked in the object starting at start address. The current card size in 512 bytes. Consider an object with start 500 and size 20, so this object lives within 2 cards. We will check the card associated with the address 500. Once this iteration is done, we will check whether start + card_size < end => 500 + 512 < 520. This is false, so we will no longer scan the second card. The algorithm was expecting the start address to be aligned to the card start, which is what the fix does.

This bug is severe, but, in practice, this code path is not as frequent. This bug would only affect objects greater than 8k, that are not arrays.

Fixes#124941

`sgen_card_table_region_begin_scanning` needs to determine whether any cards are marked in the object starting at `start` address. The current card size in 512 bytes. Consider an object with start 500 and size 20, so this object lives within 2 cards. We will check the card associated with the address 500. Once this iteration is done, we will check whether `start + card_size < end` => `500 + 512 < 520`. This is false, so we will no longer scan the second card. The algorithm was expecting the start address to be aligned to the card start, which is what the fix does. This bug is severe, but, in practice, this code path is not as frequent. This bug would only affect objects greater than 8k, that are not arrays.

dotnet-policy-service · 2026-03-03T13:44:09Z

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

Copilot

Pull request overview

Fixes SGen card-table scanning for large (LOS) non-array objects when the object start address is not aligned to a card boundary, ensuring all cards that overlap the object are checked for marks before deciding whether to scan the object.

Changes:

Align the start address down to the containing card boundary in sgen_card_table_region_begin_scanning (overlapping-cards configuration).
Ensures multi-card objects that begin mid-card do not skip subsequent cards during the per-card iteration.

lateralusX

LGTM!

BrzVlad · 2026-03-05T11:20:13Z

/backport to release/9.0-staging

BrzVlad · 2026-03-05T11:20:21Z

/backport to release/10.0

github-actions · 2026-03-05T11:20:27Z

Started backporting to release/9.0-staging (link to workflow run)

github-actions · 2026-03-05T11:20:35Z

Started backporting to release/10.0 (link to workflow run)

@BrzVlad

… objects (#125212) Backport of #125116 to release/9.0-staging /cc @BrzVlad ## Customer Impact - [x] Customer reported - [ ] Found internally In some cases, cards marked for non-array LOS objects (objects with size greater than 8K) were being ignored. This means that the GC could fail to observe that some object refs were stored inside these large objects. This can result in GC crashes or other undefined behavior. This can impact all mono workloads. This issue was confirmed to be hit by a customer who also investigated it via a GC debug flag. There are other undiagnosed GC crashes that might hopefully be fixed by this. ## Regression - [ ] Yes - [x] No ## Testing Was able to create a console app reproducing this bug. Validated the fix. ## Risk Low. The fix just does an address alignment, in order to scan correctly an additional card. Co-authored-by: Vlad Brezae <brezaevlad@gmail.com>

#125213) Backport of #125116 to release/10.0 ## Customer Impact - [x] Customer reported - [ ] Found internally In some cases, cards marked for non-array LOS objects (objects with size greater than 8K) were being ignored. This means that the GC could fail to observe that some object refs were stored inside these large objects. This can result in GC crashes or other undefined behavior. This can impact all mono workloads. This issue was confirmed to be hit by a customer who also investigated it via a GC debug flag. There are other undiagnosed GC crashes that might hopefully be fixed by this. ## Regression - [ ] Yes - [x] No ## Testing Was able to create a console app reproducing this bug. Validated the fix. ## Risk Low. The fix just does an address alignment, in order to scan correctly an additional card. Co-authored-by: Vlad Brezae <brezaevlad@gmail.com>

BrzVlad requested a review from steveisok as a code owner March 3, 2026 13:43

CopilotAI review requested due to automatic review settings March 3, 2026 13:43

BrzVlad requested a review from vitek-karas as a code owner March 3, 2026 13:43

BrzVlad added the area-GC-mono label Mar 3, 2026

dotnet-policy-serviceBot assigned BrzVlad Mar 3, 2026

BrzVlad requested a review from lateralusX March 3, 2026 13:43

Copilotstarted reviewing on behalf of BrzVlad March 3, 2026 13:44 View session

CopilotAI reviewed Mar 3, 2026
View reviewed changes

lateralusX approved these changes Mar 4, 2026
View reviewed changes

BrzVlad merged commit 79898c7 into dotnet:mainMar 5, 2026
84 checks passed

This was referenced Mar 5, 2026
[release/9.0-staging] [mono][sgen] Fix card scanning in LOS non-array objects #125212
Merged
[release/10.0] [mono][sgen] Fix card scanning in LOS non-array objects #125213
Merged

dotnet-maestroBot mentioned this pull request Mar 6, 2026
[main] Source code updates from dotnet/runtime dotnet/dotnet#5269
Merged

CopilotAI mentioned this pull request Mar 8, 2026
Add test program, build script, and SGen card scanning fix (dotnet/runtime #125116) EdgeOfAssembly/mono#2
Merged
5 tasks

github-actionsBot locked and limited conversation to collaborators Apr 5, 2026