Assert failure: executionAborted in GcInfoDecoder::EnumerateLiveSlots

[jakobbotsch]

Build Information

Build: https://dev.azure.com/dnceng-public/public/_build/results?buildId=678333&view=results
Build error leg or test failing:
Example console log: https://helixre8s23ayyeko0k025g8.blob.core.windows.net/dotnet-runtime-refs-pull-102261-merge-e822cbb23a0f465186/LibraryImportGenerator.Unit.Tests/1/console.c3aa79dd.log?helixlogtype=result

/root/helix/work/workitem/e /root/helix/work/workitem/e
  Discovering: LibraryImportGenerator.Unit.Tests (method display = ClassAndMethod, method display options = None)
  Discovered:  LibraryImportGenerator.Unit.Tests (found 185 of 190 test cases)
  Starting:    LibraryImportGenerator.Unit.Tests (parallel test collections = on [2 threads], stop on fail = off)
    LibraryImportGenerator.UnitTests.Compiles.ValidateSnippetsWithMarshalType [SKIP]
      No current scenarios to test.

Assert failure(PID 28 [0x0000001c], Thread: 73 [0x0049]): executionAborted
    File: /__w/1/s/src/coreclr/vm/gcinfodecoder.cpp:801
    Image: /root/helix/work/correlation/dotnet

Maybe related to #101890?

Error Message

Fill the error message using step by step known issues guidance.

{
  "ErrorMessage": "executionAborted",
  "BuildRetry": false,
  "ExcludeConsoleLog": false
}

Known issue validation

Build: 🔎 https://dev.azure.com/dnceng-public/public/_build/results?buildId=678333
Error message validated: [executionAborted]
Result validation: ❌ Known issue did not match with the provided build.
Validation performed at: 5/17/2024 8:39:56 AM UTC

Report

Build	Definition	Test	Pull Request
698579	dotnet/runtime	LibraryImportGenerator.Unit.Tests.WorkItemExecution	#101580
2455288	dotnet-runtime	LibraryImportGenerator.Unit.Tests.WorkItemExecution

Summary

24-Hour Hit Count	7-Day Hit Count	1-Month Count
0	0	2

[jakobbotsch]

Also cc @VSadov, I'm not familiar with the logic here, but wonder if it could be related to the new GC safe points.

[dotnet-policy-service]

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

[VSadov]

Also cc @VSadov, I'm not familiar with the logic here, but wonder if it could be related to the new GC safe points.

With interruptible GC safe points we can stress test each and every safe point.
In the past we would skip a good portion of safe points - JIT helpers, direct calls, for example would not be stress tested.

So - the change to safe points could be involved here, but it could also expose some existing bug.
(we did not see that when the change was merged, but there is a possibility of some nondeterministic bug)

Does this happen without the PR change?

[jakobbotsch]

Does this happen without the PR change?

I don't know, I haven't investigated.
Happened again in the recent libraries-jitstress run:
Pipeline run: https://dev.azure.com/dnceng-public/public/_build/results?buildId=690710&view=results
Job name: net9.0-linux-Release-arm-disabler2r
Console log: https://helixre8s23ayyeko0k025g8.blob.core.windows.net/dotnet-runtime-refs-heads-main-705beed46fcf4015ad/LibraryImportGenerator.Unit.Tests/1/console.f4051e9b.log?helixlogtype=result

[jakobbotsch]

Saw one on linux-x64 as well in https://dev.azure.com/dnceng-public/public/_build/results?buildId=692730&view=results.
Console log: https://helixre107v0xdcypoyl9e7f.blob.core.windows.net/dotnet-runtime-refs-pull-102808-merge-ca406cfc9a8448aea7/LibraryImportGenerator.Unit.Tests/1/console.b56c6cd1.log?helixlogtype=result

[davidwrighton]

Happened again on linux-arm https://dev.azure.com/dnceng-public/public/_build/results?buildId=698579&view=ms.vss-test-web.build-test-results-tab&runId=17382094&resultId=208376&paneView=dotnet-dnceng.dnceng-build-release-tasks.helix-test-information-tab

Console log
https://helixre8s23ayyeko0k025g8.blob.core.windows.net/dotnet-runtime-refs-pull-101580-merge-24599464203f4fedbf/LibraryImportGenerator.Unit.Tests/1/console.4e5f55dd.log?helixlogtype=result

[VSadov]

Always on arm32 and always in LibraryImportGenerator.Unit.Tests

The failure is strange though. It means that we try to initiate a stack walk in a fully-interruptible method, but the IP happens to not be in one of the interruptible ranges. It is hard to think of how this could happen as anything that leads to stack walks should at some point ask "is this IP interruptible?".

[VSadov]

The last failure is interesting as it is not in a JIT stress run.