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

@filipnavara - could it from your changes from #111451?

Very likely, I will have a look.

The dumps I downloaded from Helix show incorrect values of the asserted local variables, so it's not of much help.

Presumably the condition can happen when two successive stores to SP+n and FP-m get rewritten to a pair-wise store to SP+n due to the optimization in lvaFrameAddress. When emitting the GC info we suppress the optimization and it would lead to the assert.

Looking at the code I suppose that the problem would only be the assert itself and changing it to assert(FPbased == FPbased2 || FPbased != (id->idReg3() == REG_FP)); would likely make it pass. As far as I can see, the calls emitGCvarLiveUpd or emitGCvarDeadUpd would still get correct values.

I need to verify that this theory is actually correct and I will only get to my win-arm machine later today or Monday. I submitted a PR with revert to unblock the CI.

This issue is indeed a variation of the case described in the comment above. For example, in the System.Collections.Tests in the System.Runtime.Serialization.Formatters.Binary.ObjectWriter:Serialize(System.Object,System.Runtime.Serialization.Formatters.Binary.BinaryFormatterWriter) method we end up with the following:

;  V09 OutArgs      [V09    ] (  1,  1   )  struct ( 8) [sp+0x00]  do-not-enreg[XS] addr-exposed "OutgoingArgSpace"
;  V26 tmp17        [V26,T12] (  3, 12   )     ref  ->  [fp-0x68]  class-hnd exact spill-single-def "dup spill" <System.Runtime.Serialization.Formatters.Binary.WriteObjectInfo>

The lvaFrameAddress optimization rewrites tmp17 to sp+0x08 and we end up with

;  V09 OutArgs      [V09    ] (  1,  1   )  struct ( 8) [sp+0x00]  do-not-enreg[XS] addr-exposed "OutgoingArgSpace"
;  V26 tmp17        [V26,T12] (  3, 12   )     ref  ->  [sp+0x08]  class-hnd exact spill-single-def "dup spill" <System.Runtime.Serialization.Formatters.Binary.WriteObjectInfo>

Later on, two stores get coalesced into single stp pair-wise write (expected) but the GC info code doesn't handle that correctly. I think I know how to fix it but I need to run more tests to verify the correctness of the fix.