-
Notifications
You must be signed in to change notification settings - Fork 5k
Assert failure '!CREATE_CHECK_STRING(bSmallObjectHeapPtr || bLargeObjectHeapPtr)' #111922
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
Tagging subscribers to this area: @JulieLeeMSFT, @jakobbotsch |
@AndyAyersMS, PTAL. |
Seems like this happened before #111937, so likely something else. Unfortunately, the log is gone already. Will close and hope we get a repro later. |
https://helixr1107v0xdcypoyl9e7f.blob.core.windows.net/dotnet-runtime-refs-pull-112151-merge-4df3d17f7ce144de85/System.Text.RegularExpressions.Tests/1/console.e0976529.log?helixlogtype=result has a more recent repro and hasn't been purged yet, so will look at that. |
This is a very generic GC failure message and the various repros above seem to be quite diverse. So could be more than one underlying issue. |
Dump from example run -- linux arm64 is not very useful? Can't get very far with either lldb or dotnet-dump. Going to see if I can get a local repro. |
Looked at failure in 961085 -- crash dump is not useful. Can't repro locally yet. |
@tommcdon am I being dumb or is linux crashdump debugging not working well? I can't get anywhere with the dump in the helix item just above, lldb's sos is unable to find the runtime. eg
|
Seems to have stopped happening, so will close. |
Failed in pipeline |
This is a very generic assert, so the recent failure may not be the same issue we were trying to track down before. Let me see if the downloaded bits will repro the latest problem. |
No luck yet. Have now run this ~200 times. Will let it go overnight. |
Overnight run is closing in on 600 more attempts with no repro. Going to look at the dump but lately I have had no luck with any sort of linux crash dump. |
@AndyAyersMS I found a Fuzzlyn test case that reliably hits this assert (win-x64). The Fuzzlyn reducer failed to reduce it to something smaller. Build a release version of the test (
|
@BruceForstall thanks, this should help. |
The latest repro is stack allocation related. We fail to properly retype a storeind in I already had reworked this bit of code in my prototyping of general field-wise analysis, and picking up that change fixes the issue. |
Retype GT_STOREIND based on the store address, not the store data, since we need to know if we are retyping fields, and only know that when propagating from the local that forms the store address. Fixes dotnet#111922.
After looking at this some more, there is another problem -- for byref args the caller owns the GC reporting. So we can't retype the fields, and so we can't stack allocate any of the referents. |
Two fixes: * we can't retype gc struct params, as their GC info is reported by the caller. Instead we must mark them as escaping. * when retyping GT_STOREIND we should always use the stored data's new type Fixes dotnet#111922.
Uh oh!
There was an error while loading. Please reload this page.
Hit in
libraries-pgo
. Example run (console log). cc @dotnet/jit-contribKnown Issue Error Message
Fill the error message using step by step known issues guidance.
Known issue validation
Build: 🔎 https://dev.azure.com/dnceng-public/public/_build/results?buildId=954772
Error message validated:
[!CREATE_CHECK_STRING(bSmallObjectHeapPtr || bLargeObjectHeapPtr)
]Result validation: ✅ Known issue matched with the provided build.
Validation performed at: 2/18/2025 8:42:54 AM UTC
Report
Summary
The text was updated successfully, but these errors were encountered: