Assert failure(PID 13812 [0x000035f4], Thread: 14128 [0x3730]): promoted_bytes (heap_number) == promoted #100035
Assignees
Labels
Comments
AndyAyersMS
added
blocking-clean-ci
|
Tagging subscribers to this area: @dotnet/area-infrastructure-libraries |
dotnet-policy-service
bot
added
the
untriaged
AndyAyersMS
added
area-GC-coreclr
and removed
untriaged
|
@markples since we were chatting about incorrect promoted bytes reporting today. Perhaps this is related? |
|
The other one occurs when a normal GC interferes with the bookkeeping of a BGC and leads to a BGC assertion. This isn't doing that, but perhaps the reverse could occur. |
|
Adding @Maoni0 as well in case this is related to any recent change. |
|
@dotnet/runtime-infrastructure there are many CI job failures for this, but none has a dump attached. It did collect a stack trace locally, so not sure why the dump has not been uploaded? |
|
This appears to be a compiler bug on x64 windows. dprintfs are nops in this build. The relevant asm is extracted (way) below. C++ (manually preprocessed a bit): inline
size_t gc_heap::get_promoted_bytes()
{
if (!survived_per_region)
{
dprintf (...);
return 0;
}
dprintf (...);
size_t promoted = 0;
for (size_t i = 0; i < region_count; i++)
{
if (survived_per_region[i] > 0)
{
heap_segment* region = get_region_at_index (i);
dprintf (...)
promoted += survived_per_region[i];
}
}
dprintf (...);
assert (promoted_bytes (heap_number) == promoted);
return promoted;Full asm: Relevant asm: If I'm reading it correctly, the minimum is always going to be zero due to xmm4 being zero. The compare will generate all 1s if the array value is zero, all 0s otherwise. I haven't found the definition of xmm6 (but from other examples is likely to be all 1s) or what the double and-not is doing. Perhaps replacing both of those with [edit: details in last paragraph] |
|
adding a bit of detail why we suspected this was a compiler issue to begin with - we could see the 2 values were indeed the same if the calculation in the loop was done correctly. I looked at multiple repros and if I added up what's in but in the debugger
|
|
Failed in: runtime-coreclr jitstress 20240321.2 Failed tests: Error message: Stack trace: More failures: runtime-coreclr pgo 20240322.1 |
|
This is having fairly widespread impact, would appreciate it if we could get some kind of mitigation in place soon. |
|
yeah we will need to workaround by disabling optimizations for this method in the interim. Very likely this was triggered by the compiler update from last week. |
|
This affects servicing branches as well. Seen in a 8.0-staging PR: |
|
we plan to move to Release version of the toolset. PR for backport: #100622 |
jeffschwMSFT
removed
the
blocking-clean-ci
|
removing blocking-clean-ci as it has not failed in 30 days
|
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Build Information
Build: https://dev.azure.com/dnceng-public/cbb18261-c48f-4abb-8651-8cdcb5474649/_build/results?buildId=610011
Build error leg or test failing: GC\API\NoGCRegion\Callback_Svr\Callback_Svr.cmd
Pull request: #99992
Error Message
Fill the error message using step by step known issues guidance.
{ "ErrorMessage": "promoted_bytes (heap_number) == promoted", "ErrorPattern": "", "BuildRetry": false, "ExcludeConsoleLog": false }FYI @dotnet/gc
Known issue validation
Build: 🔎 https://dev.azure.com/dnceng-public/public/_build/results?buildId=610011
Error message validated:
[promoted_bytes (heap_number) == promoted]Result validation: ✅ Known issue matched with the provided build.
Validation performed at: 3/20/2024 7:47:36 PM UTC
Report
Summary
The text was updated successfully, but these errors were encountered: