Assert failure HasPerInstInfo() methodtable.h Line: 2908

[ViktorHofer]

https://dnceng.visualstudio.com/public/_build/results?buildId=535480&view=ms.vss-test-web.build-test-results-tab&runId=16999826&paneView=debug

Configuration: netcoreapp5.0-OSX-Release-x64-CoreCLR_checked-OSX.1013.Amd64.Open

Dump: https://helix.dot.net/api/2019-06-17/jobs/1d28c181-b612-4d7b-b57c-ad158d0a1b9e/workitems/System.Composition.Hosting.Tests/files/core.51410

  Discovering: System.Composition.Hosting.Tests (method display = ClassAndMethod, method display options = None)
  Discovered:  System.Composition.Hosting.Tests (found 66 test cases)
  Starting:    System.Composition.Hosting.Tests (parallel test collections = on, max threads = 4)

Assert failure(PID 51410 [0x0000c8d2], Thread: 3649813 [0x37b115]): HasPerInstInfo()
    File: /Users/runner/runners/2.165.0/work/1/s/src/coreclr/src/vm/methodtable.h Line: 2908
    Image: /private/tmp/helix/working/AA450997/p/dotnet


Assert failure(PID 51410 [0x0000c8d2], Thread: 3649814 [0x37b116]): HasPerInstInfo()
    File: /Users/runner/runners/2.165.0/work/1/s/src/coreclr/src/vm/methodtable.h Line: 2908
    Image: /private/tmp/helix/working/AA450997/p/dotnet

./RunTests.sh: line 161: 51410 Abort trap: 6           (core dumped) "$RUNTIME_PATH/dotnet" exec --runtimeconfig System.Composition.Hosting.Tests.runtimeconfig.json --depsfile System.Composition.Hosting.Tests.deps.json xunit.console.dll System.Composition.Hosting.Tests.dll -xml testResults.xml -nologo -nocolor -notrait category=IgnoreForCI -notrait category=OuterLoop -notrait category=failing -notrait category=nonnetcoreapptests -notrait category=nonosxtests $RSP_FILE
/private/tmp/helix/working/AA450997/w/A59A091E/e
----- end Tue Feb 25 00:51:44 PST 2020 ----- exit code 134 ----------------------------------------------------------
exit code 134 means SIGABRT Abort. Managed or native assert, or runtime check such as heap corruption, caused call to abort(). Core dumped.

cc @jkotas

[jkotas]

@fadimounir Could you please take a look? Looks like regression from your change.

[fadimounir]

Taking a look

[fadimounir]

Still don't have more info other than callstack and point of failure. I couldn't repro locally, and i'm still digging into the crash dump to understand what's going on.
The threads in which the assert is triggered are for some odd reason not listed as part of the threads listed in clrthreads sos command

[fadimounir]

I couldn't figure out from the dumps where the memory corruption came from. Seems to be a corruption where something overwrote the MethodTable pointer stored in the MethodDescChunk of a method, and this is what lead to the assert.

Interestingly, in the dump I was looking at, the 2 threads hitting the assert were not threads listed by the clrthreads sos command in lldb. I don't know what this means, but from the callstack, the threads seem to still be actively running test code, so I don't know what they would not be listed.

On another note, the analytics for the runtime pipeline are not showing any similar failures other than the spike around Feb 25/26: https://dev.azure.com/dnceng/public/_test/analytics?definitionId=686&contextType=build
Coincidence maybe? I would have expected more failures here.

In any case, I've created a build with some logging and letting it run on a linux VM to see if it will fail