Zero initialize FrameInfo so that we don't mistake an InlineCallFrame for a CLRToCOMMethodFrame

[steveisok]

This one was a doozy.

If you try to step in to a static function and the static cctor hasn't run, the debugger will treat it as a go. Moving the static helpers to managed altered the debugger flow such that you would have managed -> native interop -> managed (implied .cctor) frames. The debugger would detect the last managed one is an implied .cctor and step out. When it stepped out to the next managed frame, it would then incorrectly calculate the offset and issue a breakpoint the instruction before the qcall into native code. Thus, the code already ran and it's effectively a go.

After a bunch of logging and discussion, I at first thought the stackwalker was at fault where it somehow ignored the unmanaged frames. I then noticed we have a block that intentionally suppresses native frames when stepping out similar to what is now happening.

After even more logging, I noticed that pInfo->fIgnoreThisFrameIfSuppressingUMChainFromCLRToCOMMethodFrameGeneric was true even though nothing ran to set it that way. This lead to the fix where we zero initialize a FrameInfo instance to make sure that bool is false.

Note: I would not be surprised if there are other interop stepping issues lurking. Additionally, there are other places where we don't zero initialize various structs on the stack. As a follow up, we should do that in order to avoid this kind of madness.

Fixes #114820

[Copilot]

Pull Request Overview

This PR ensures a FrameInfo struct is zero-initialized in TrackUMChain to avoid uninitialized boolean flags causing incorrect debugger stepping behavior when static constructors haven’t run.

• Value-initialize FrameInfo f so fIgnoreThisFrameIfSuppressingUMChainFromCLRToCOMMethodFrameGeneric is false by default.
• Prevents the debugger from mistaking an InlineCallFrame for a CLRToCOMMethodFrame and stepping out incorrectly.

Comments suppressed due to low confidence (1)

src/coreclr/debug/ee/frameinfo.cpp:1182

• Add a debugger stepping test to verify that FrameInfo is correctly zero-initialized and that InlineCallFrames are not mistaken for CLRToCOMMethodFrame after this change.

        FrameInfo f = {};

[tommcdon]

LGTM!

[steveisok]

/ba-g Infra failure is too generic on win-x86 legs

[dotnet-policy-service]

Tagging subscribers to this area: @steveisok, @dotnet/dotnet-diag
See info in area-owners.md if you want to be subscribed.