baseservices/exceptions/generics/nested-try-catch04 crashing under jitstress/gcstress on arm

[AndyAyersMS]

https://dev.azure.com/dnceng-public/public/_build/results?buildId=1081377&view=ms.vss-test-web.build-test-results-tab

Linux arm32

export DOTNET_TieredCompilation=0
export DOTNET_GCStress=0xC
export DOTNET_JitStress=1

22:36:04.994 Running test: baseservices/exceptions/generics/nested-try-catch04/nested-try-catch04.dll
[createdump] Gathering state for process 33 corerun
[createdump] Crashing thread 0021 signal 11 (000b)


MethodTable::GetFlag(MethodTable::WFLAGS_HIGH_ENUM) const at /__w/1/s/src/coreclr/vm/methodtable.h:3818:16
 (inlined by) MethodTable::HasComponentSize() const at /__w/1/s/src/coreclr/vm/methodtable.h:1823:16
 (inlined by) MethodTable::GetComponentSize() at /__w/1/s/src/coreclr/vm/methodtable.h:1845:16
 (inlined by) MethodTable::SanityCheck() at /__w/1/s/src/coreclr/vm/methodtable.cpp:6277:5
MethodTable::Validate() at /__w/1/s/src/coreclr/vm/methodtable.cpp:8586:5
Object::ValidateInner(int, int, int) at /__w/1/s/src/coreclr/vm/object.cpp:548:9
TGcInfoDecoder<ARM32GcInfoEncoding>::ReportRegisterToGC(int, unsigned int, REGDISPLAY*, unsigned int, void (*)(void*, OBJECTREF*, unsigned int), void*) at /__w/1/s/src/coreclr/vm/gcinfodecoder.cpp:1734:5
TGcInfoDecoder<ARM32GcInfoEncoding>::EnumerateLiveSlots(REGDISPLAY*, bool, unsigned int, void (*)(void*, OBJECTREF*, unsigned int), void*) at /__w/1/s/src/coreclr/vm/gcinfodecoder.cpp:0:21
EECodeManager::EnumGcRefs(REGDISPLAY*, EECodeInfo*, unsigned int, void (*)(void*, OBJECTREF*, unsigned int), void*, unsigned int) at /__w/1/s/src/coreclr/vm/eetwain.cpp:1332:24
GcStackCrawlCallBack(CrawlFrame*, void*) at /__w/1/s/src/coreclr/vm/gcenv.ee.common.cpp:0:18

[dotnet-policy-service]

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

[JulieLeeMSFT]

@amanasifkhalid, PTAL.

[amanasifkhalid]

I'm afraid I don't have any arm32 hardware to run this on -- @AndyAyersMS do you still have your Raspberry Pi?

[AndyAyersMS]

I'm afraid I don't have any arm32 hardware to run this on -- @AndyAyersMS do you still have your Raspberry Pi?

I do, I can take this one.

[AndyAyersMS]

I can repro, we are failing looking at GC roots of

Gen`1[ValX2`2[ValX2`2[ValX1`1[int],ValX3`3[int,System.__Canon,ValX1`1[ValX2`2[int,System.__Canon]]]],ValX2`2[ValX1`1[int],ValX3`3[int,System.__Canon,ValX1`1[ValX2`2[int,System.__Canon]]]]]]:ExceptionTest(bool):this [FullOpts, IL size=52, code size=452, hash=0xaaa4b1bf JitStress]

at offset 94

IN000c: 000058      movt    r12, 0xed8c
IN000d: 00005C      blx     r12		// CORINFO_HELP_PROF_FCN_LEAVE
IN000e: 00005E      movw    r12, 0x5678

[AndyAyersMS]

Register being reported is r0 -- looks like it comes to back to life at the call despite being killed just a bit earlier:

Generating: N365 (  0,  0) [002281] -----+-----                            RETURN    void   REG NA $VN.Void
IN0009:             movw    r0, 0x955d
IN000a:             movt    r0, 0xed8c
IN000b:             movw    r12, 0x955d
IN000c:             movt    r12, 0xed8c
NoGC Call: savedSet=57FF {r0 r1 r2 r3 r4 r5 r6 r7 r8 r9 r10 r12 lr}
Call: GCvars=00000002 {V00}, gcrefRegs=0001 {r0}, byrefRegs=0000 {}
[13] Rec call GC vars = 00000002
IN000d:             blx     r12		// CORINFO_HELP_PROF_FCN_LEAVE
Marking regs modified: [r0-r3 r12 lr f0-f15] ([r0-r4 r10 r12 lr] => [r0-r4 r10 r12 lr f0-f15])
Added IP mapping: EPILOG (G_M20032_IG03,ins#12,ofs#40) label

...

IN0009: 00004C      movw    r0, 0x955d
                       ; gcrRegs -[r0]
IN000a: 000050      movt    r0, 0xed8c
IN000b: 000054      movw    r12, 0x955d
IN000c: 000058      movt    r12, 0xed8c
IN000d: 00005C      blx     r12		// CORINFO_HELP_PROF_FCN_LEAVE
                       ; gcrRegs +[r0]
IN000e: 00005E      movw    r12, 0x5678

[AndyAyersMS]

I think what's happening is that we're in a method where we have a generic catch clause type, this is in r0 and must be kept alive, yet the profiler callback knows that r0 is basically dead, and so needs to use it, but the attempt to clear the GC liveness of r0 fails because it is overridden by the keep-alive logic. So we "resurrect" the GC ref in r0 at the call site but have already trashed its value.

@jakobbotsch I think you were working in this area recently, any thoughts? Should we override the "keep alive" override (presumably this exists to be able to look up the generic context if an exception happens, or similar, and we are past the point where such things can happen?).

I am not sure moving the value of r0 elsewhere works as its location is likely specified somewhere in the GC info? But maybe we (for similar reasons as the above) it doesn't matter as we won't look for it in its GC info reported place.