Stackoverflow at startup with CoreCLR on ios simulator x64

[rolfbjarne]

Description

When running an iOS project in the x64 simulator, and when using CoreCLR, the app crashes at startup with:

Stack overflow.
Repeated 1813 times:
--------------------------------
   at System.Runtime.CompilerServices.RuntimeHelpers.CallDefaultConstructor(System.Object*, Void (System.Object), System.Exception*)
--------------------------------
   at System.AppContext.Setup(Char**, Char**, Int32, System.Exception*)

Reproduction Steps

git clone https://github.com/dotnet/macios --recurse-submodules
cd macios
git checkout darc-release/11.0.1xx-preview5-ac83f574-df9a-48c9-ab93-f3bcb3a825ba
git reset --hard 51283bed16305c25c2b6c19891d8e5a365e09c71
git cherry-pick f708cd61aa348284654db81c802b9362fbc54748
git cherry-pick 0e55db3f754412b770d9ba1c3e6d630ad56ae29a
git cherry-pick 58ead49e76836ff1462fabdd7a94cc4ab04c81fa
./configure --disable-all-platforms --enable-ios
make all -j8
make install -j8
cd tests/monotouch-test/dotnet/iOS
dotnet run -r iossimulator-x64

Expected behavior

Successful app launch.

Actual behavior

Stack overflow.
Repeated 1813 times:
--------------------------------
   at System.Runtime.CompilerServices.RuntimeHelpers.CallDefaultConstructor(System.Object*, Void (System.Object), System.Exception*)
--------------------------------
   at System.AppContext.Setup(Char**, Char**, Int32, System.Exception*)

Regression?

Yes

Known Workarounds

No response

Configuration

This happens in the latest .NET 11 maestro bump:

• .NET 11: [net11.0] Update dependencies from dotnet/dotnet macios#25379 (introduced with this PR, which is unfortunately rather old)
• .NET 11 P5: [release/11.0.1xx-preview5] Update dependencies from dotnet/dotnet macios#25607 (not introduced with this PR, previous bump PR was merged despite test failures)

Other information

Also happens on tvOS. Does not happen on Mac Catalyst.

[dotnet-policy-service]

Tagging subscribers to 'os-ios': @vitek-karas, @kotlarmilos, @steveisok, @akoeplinger
See info in area-owners.md if you want to be subscribed.

[dotnet-policy-service]

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

[kotlarmilos]

I've narrowed this down but I'm stuck on the final root cause, and I couldn't reproduce it locally. RuntimeHelpers.CallDefaultConstructor self-recurses ~1800x from AppContext.Setup. Tracing the dispatch:

• CallDefaultConstructor reverse-pinvokes into the managed [UnmanagedCallersOnly] CallDefaultConstructor(object* pObj, delegate*<object,void> pCtor, Exception*) via UnmanagedCallersOnlyCaller, passing the real constructor's code address as pCtor
• The managed side does pCtor(*pObj), which is a calli
• The recursion means pCtor resolves back to CallDefaultConstructor itself instead of the target constructor.

My initial suspicion was the calli-cookie cache (#127016) and its iOS fix (#127876), but that fix is in the build and it always recomputes the cookie fresh. So this looks like the stub or arguments being computed incorrectly, which points at the reverse-pinvoke and call-stub generation path mishandling the pointer-arg signature rather than the cookie cache. #127758 fixed one reverse-pinvoke arg-iteration case, but this pointer-arg signature may not be covered.

@rolfbjarne Do you have a native backtrace at the recursion from lldb? It would also help to get the values of pCtor and pObj at the managed CallDefaultConstructor frame, to confirm whether pCtor points back at CallDefaultConstructor itself or at the real constructor.

/cc: @BrzVlad @janvorli

[BrzVlad]

Is this x64 only ? @kotlarmilos did you try on x64 as well ?