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 ?

[jkotas]

The recursion means pCtor resolves back to CallDefaultConstructor itself instead of the target constructor.

Not necessarily. It can mean that e.g. runtime hit an exception while trying to execute the default constructor, it is trying to create a managed object for the exception, and hitting the same error again.

[rolfbjarne]

lldb stack trace:

    frame #12688: 0x000000010efb0335 libcoreclr.dylib`void UnmanagedCallersOnlyCaller::InvokeThrowing<Object**, unsigned long>(Object**, unsigned long) + 149
    frame #12689: 0x000000010efb020b libcoreclr.dylib`CallDefaultConstructor(Object*) + 155
    frame #12690: 0x000000010efb5607 libcoreclr.dylib`EEException::CreateThrowable() + 183
    frame #12691: 0x000000010f0069d0 libcoreclr.dylib`InterpExecMethod(InterpreterFrame*, InterpMethodContextFrame*, InterpThreadContext*, ExceptionClauseArgs*) + 26192
    frame #12692: 0x000000010ef5cd30 libcoreclr.dylib`ExecuteInterpretedMethod + 448
    frame #12693: 0x000000010f0f1daf libcoreclr.dylib`InterpreterStubRetVoid + 15
    frame #12694: 0x000000010f0f1d7a libcoreclr.dylib`InterpreterStub + 250
    frame #12695: 0x000000010efb0335 libcoreclr.dylib`void UnmanagedCallersOnlyCaller::InvokeThrowing<Object**, unsigned long>(Object**, unsigned long) + 149
    frame #12696: 0x000000010efb020b libcoreclr.dylib`CallDefaultConstructor(Object*) + 155
    frame #12697: 0x000000010efb5607 libcoreclr.dylib`EEException::CreateThrowable() + 183
    frame #12698: 0x000000010f0069d0 libcoreclr.dylib`InterpExecMethod(InterpreterFrame*, InterpMethodContextFrame*, InterpThreadContext*, ExceptionClauseArgs*) + 26192
    frame #12699: 0x000000010ef5cd30 libcoreclr.dylib`ExecuteInterpretedMethod + 448
    frame #12700: 0x000000010f0f1daf libcoreclr.dylib`InterpreterStubRetVoid + 15
    frame #12701: 0x000000010f0f1d7a libcoreclr.dylib`InterpreterStub + 250
    frame #12702: 0x000000010eed17dd libcoreclr.dylib`void UnmanagedCallersOnlyCaller::InvokeThrowing<char16_t const**, char16_t const**, int>(char16_t const**, char16_t const**, int) + 157
    frame #12703: 0x000000010eed11e7 libcoreclr.dylib`CorHost2::CreateAppDomainWithManager(char16_t const*, unsigned int, char16_t const*, char16_t const*, int, char16_t const**, char16_t const**, unsigned int*) + 423
    frame #12704: 0x000000010f10a1e0 libcoreclr.dylib`coreclr_initialize + 864
    frame #12705: 0x000000010dc89cf3 libxamarin-dotnet-coreclr-debug.dylib`xamarin_bridge_vm_initialize(propertyCount=6, propertyKeys=0x000000030e9cbc70, propertyValues=0x000000030e9cbc30) at coreclr-bridge.m:495:7
    frame #12706: 0x000000010dc7e4bc libxamarin-dotnet-coreclr-debug.dylib`xamarin_vm_initialize at runtime.m:2573:12
    frame #12707: 0x000000010dc8fb2d libxamarin-dotnet-coreclr-debug.dylib`xamarin_main(argc=1, argv=0x000000030e9cc4b0, launch_mode=XamarinLaunchModeApp) at monotouch-main.m:411:2
    frame #12708: 0x00000001050ee7f4 monotouchtest`main(argc=1, argv=0x000000030e9cc4b0) at main.x86_64.mm:50:11
    frame #12709: 0x000000010db8ed4d dyld_sim`start_sim + 10
    frame #12710: 0x00000002058f0b28 dyld`start + 3240

(lldb)
frame #12507: 0x000000010efb020b libcoreclr.dylib`CallDefaultConstructor(Object*) + 155
libcoreclr.dylib`CallDefaultConstructor:
->  0x10efb020b <+155>: leaq   -0x40(%rbp), %rdi
    0x10efb020f <+159>: callq  0x10eefa7d0    ; GCFrame::~GCFrame()
    0x10efb0214 <+164>: movq   0x20efb5(%rip), %rax ; (void *)0x000000013c116e70: __stack_chk_guard
    0x10efb021b <+171>: movq   (%rax), %rax
    0x10efb021e <+174>: cmpq   -0x10(%rbp), %rax
    0x10efb0222 <+178>: jne    0x10efb0256    ; <+230>
    0x10efb0224 <+180>: addq   $0x48, %rsp
    0x10efb0228 <+184>: popq   %rbx
    0x10efb0229 <+185>: popq   %rbp
    0x10efb022a <+186>: retq
    0x10efb022b <+187>: leaq   0x1e6eac(%rip), %rdx ; ".ctor"
    0x10efb0232 <+194>: leaq   -0x40(%rbp), %rdi
    0x10efb0236 <+198>: xorl   %esi, %esi
    0x10efb0238 <+200>: callq  0x10ef049d0    ; SString::SString(SString::tagUTF8, char const*)
    0x10efb023d <+205>: leaq   -0x40(%rbp), %rdi
    0x10efb0241 <+209>: callq  0x10ed95110    ; SString::ConvertToUnicode() const
    0x10efb0246 <+214>: movq   -0x30(%rbp), %rsi
    0x10efb024a <+218>: movl   $0x24, %edi
    0x10efb024f <+223>: callq  0x10eeec810    ; RealCOMPlusThrowNonLocalized(RuntimeExceptionKind, char16_t const*)
    0x10efb0254 <+228>: ud2
(lldb) frame inf
frame #12507: 0x000000010efb020b libcoreclr.dylib`CallDefaultConstructor(Object*) + 155

[kotlarmilos]

@jkotas was correct - the runtime hits an exception while interpreting a default constructor, tries to build the managed exception object and that re-throws the identical exception

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

This is x64 only, I couldn't reproduce it on arm64 device