Fix issue #74741 - assert failure during weak pointer scanning. #74810
Conversation
…::IsPromoted so we can zero out object pointers to objects that weren't marked. At the same time, one thread may do the same for the sync block table. When the first kind of threads validate the object, they also validate the sync block entry that may have already been zeroed - this causes an assert failure. I don't think there is any bad effect apart from the assert failure though. The fix is to simply call Object::Validate with a bVerifySyncBlock of FALSE if the object hasn't been marked.
|
Tagging subscribers to this area: @dotnet/gc Issue DetailsThe problem here is that during GCScan::GcWeakPtrScan, we call GCHeap::IsPromoted so we can zero out object pointers to objects that weren't marked. At the same time, one thread may do the same for the sync block table. When the first kind of threads validate the object, they also validate the sync block entry that may have already been zeroed - this causes an assert failure. I don't think there is any bad effect apart from the assert failure though, i.e. retail builds should work fine. The fix is to simply call Object::Validate with a bVerifySyncBlock of FALSE if the object hasn't been marked.
|
…eader::Validate with just one parameter that is used in Native AOT and the standalone GC. Fix is simply to declare, but ignore the extra parameters.
|
/backport to release/7.0 |
|
Started backporting to release/7.0: https://github.com/dotnet/runtime/actions/runs/2967163979 |
ghost
locked as resolved and limited conversation to collaborators
3 participants
The problem here is that during GCScan::GcWeakPtrScan, we call GCHeap::IsPromoted so we can zero out object pointers to objects that weren't marked. At the same time, one thread may do the same for the sync block table. When the first kind of threads validate the object, they also validate the sync block entry that may have already been zeroed - this causes an assert failure. I don't think there is any bad effect apart from the assert failure though, i.e. retail builds should work fine.
The fix is to simply call Object::Validate with a bVerifySyncBlock of FALSE if the object hasn't been marked.