Repository navigation
Assert failure: orObject->HasEmptySyncBlockInfo() #96790
Description
Error Blob
{
"ErrorMessage": "orObject->HasEmptySyncBlockInfo()",
"BuildRetry": false,
"ErrorPattern": "",
"ExcludeConsoleLog": false
}Reproduction Steps
Example run: https://dev.azure.com/dnceng-public/public/_build/results?buildId=518688&view=results
Console log: https://helixre107v0xdcypoyl9e7f.blob.core.windows.net/dotnet-runtime-refs-heads-main-938d4603b99d40ee8c/System.Linq.Tests/1/console.059191e6.log?helixlogtype=result
Assert failure(PID 3960 [0x00000f78], Thread: 1740 [0x06cc]): orObject->HasEmptySyncBlockInfo()
CORECLR! GetCLRRuntimeHost + 0x20B8E2 (0x720e4292)
CORECLR! GetCLRRuntimeHost + 0x20D873 (0x720e6223)
CORECLR! GetCLRRuntimeHost + 0x20D95F (0x720e630f)
CORECLR! GetCLRRuntimeHost + 0x1B338F (0x7208bd3f)
<no module>! <no symbol> + 0x0 (0x0dd6c86b)
<no module>! <no symbol> + 0x0 (0x0dd6c0e6)
<no module>! <no symbol> + 0x0 (0x0dd6bfc3)
<no module>! <no symbol> + 0x0 (0x0dd6bf19)
<no module>! <no symbol> + 0x0 (0x0dd6bc8a)
<no module>! <no symbol> + 0x0 (0x0cdc1b51)
File: D:\a\_work\1\s\src\coreclr\vm\gchelpers.cpp Line: 312
Image: C:\h\w\A460091B\p\dotnet.exe
----- end Tue 01/09/2024 1:02:09.32 ----- exit code -1073740286 ----------------------------------------------------------Known issue validation
Build: 🔎 https://dev.azure.com/dnceng-public/public/_build/results?buildId=518688
Error message validated: orObject->HasEmptySyncBlockInfo()
Result validation: ✅ Known issue matched with the provided build.
Validation performed at: 1/10/2024 5:48:37 PM UTC
Report
Summary
| 24-Hour Hit Count | 7-Day Hit Count | 1-Month Count |
|---|---|---|
| 9 | 45 | 56 |
Activity
[-][libraries-jitstress] Assert failure: orObject->HasEmptySyncBlockInfo()[/-][+]Assert failure: orObject->HasEmptySyncBlockInfo()[/+]BruceForstall commentedon Jan 11, 2024
Another case: https://dev.azure.com/dnceng-public/public/_build/results?buildId=523353&view=ms.vss-test-web.build-test-results-tab
BruceForstall commentedon Jan 11, 2024
I've seen this in various pipelines in the last week.
BruceForstall commentedon Jan 11, 2024
@mangod9
BruceForstall commentedon Jan 16, 2024
Another case (internal pipeline):
https://dev.azure.com/dnceng/internal/_build/results?buildId=2353335&view=ms.vss-test-web.build-test-results-tab&runId=52868327&resultId=207146&paneView=dotnet-dnceng.dnceng-build-release-tasks.helix-test-information-tab
BruceForstall commentedon Jan 16, 2024
Another:
https://dev.azure.com/dnceng-public/public/_build/results?buildId=528246&view=ms.vss-test-web.build-test-results-tab&runId=12443784&resultId=210683&paneView=dotnet-dnceng.dnceng-build-release-tasks.helix-test-information-tab
2 remaining items
jkotas commentedon Jan 18, 2024
The typical stacktrace of the crash has
GC.AllocateUninitializedArraycalled from SegmentedArrayBuilder:SegmentedArray builder was introduced by #96570 last week. We are calling and stressing
GC.AllocateUninitializedArraya lot more now than before. It is likely a pre-existing bug that #96570 exposed.The assert is complaining about syncblk index memory returned by
GCHeap::Allocnot being zeroed. We may be missing a path in GC to clear the syncblk index withGC_ALLOC_ZEROING_OPTIONAL. cc @dotnet/gcNote that we are hitting this crash on x86 only (no GC regions).
mangod9 commentedon Jan 18, 2024
Ok interesting. @cshung, would you be able to take a look since this is CI blocking? Thx!
cshung commentedon Jan 18, 2024
Is it possible to make this easier to reproduce locally?
mangod9 commentedon Jan 18, 2024
should be easy to repro given frequent failures in CI. Note that this is on x86 only.
cshung commentedon Jan 18, 2024
It maybe obvious for you, but exactly how? I have got the repo built.
Ensure syncblock is cleared with GC_ALLOC_ZEROING_OPTIONAL
jkotas commentedon Jan 18, 2024
It is documented at https://github.com/dotnet/runtime/blob/main/docs/workflow/testing/libraries/testing.md#testing-libraries . The command line for this case would be:
build.cmd -subset clr+libs+libs.tests -test -arch x86 -rc checked -c releasejkotas commentedon Jan 18, 2024
I have reviewed all allocation paths and found a few places where we are missing clearning of the syncblock: #97174
Ensure syncblock is cleared with GC_ALLOC_ZEROING_OPTIONAL (dotnet#97174
Ensure syncblock is cleared with GC_ALLOC_ZEROING_OPTIONAL (dotnet#97174