@rolfbjarne Do you have any idea on what could be the issue or another working approach on how to tests this with custom runtime and iOS template app?

I wonder if the dylib needs to be signed?

Do you get the same error if you copy:

1. An unmodified dylib from a published NuGet.
2. A lcoally built dylib, from the same hash has the published NuGet without any source code changes.

An alternative might be to try in the x64 simulator.

A note regarding E2E testing and:

Thread 0 Crashed::  Dispatch queue: com.apple.main-thread0   libsystem_platform.dylib             0x10ec25828 _platform_memset_pattern16 + 2961   libmonosgen-2.0.dylib                0x1113f0fa8 mono_arch_create_sdb_trampoline + 762   libmonosgen-2.0.dylib                0x1113a9134 mini_get_breakpoint_trampoline + 1003   libmonosgen-2.0.dylib                0x1113da7a8 mono_arch_init + 444   libmonosgen-2.0.dylib                0x1113147f8 mini_init + 8485   libmonosgen-2.0.dylib                0x11136b7d0 mono_jit_init_version + 206   libxamarin-dotnet-debug.dylib        0x110095550 xamarin_bridge_initialize + 2167   libxamarin-dotnet-debug.dylib        0x11009b8e4 xamarin_main + 17808   simulator_ICU_issue                  0x106b2b868 main + 64 (main.arm64.mm:409)9   dyld_sim                             0x10f209544 start_sim + 2010  dyld                                 0x10ed060e0 start + 2360Thread 1:0   libsystem_pthread.dylib              0x10fbe66dc start_wqthread +

We are getting this even if we build the runtime locally and configure the project file to reference the locally built runtime like:

  <PropertyGroupCondition="$(LocalBuild) == 'true'">    <RestoreAdditionalProjectSources>/Users/ivan/repos/runtime-mono/artifacts/packages/Release/Shipping</RestoreAdditionalProjectSources>  </PropertyGroup>  <ItemGroupCondition="$(LocalBuild) == 'true'">    <FrameworkReferenceUpdate="Microsoft.NETCore.App"RuntimeFrameworkVersion="8.0.3-dev" />  </ItemGroup>

However, if we build the app and manually copylibmonosgen-2.0.dylib andlibSystem.Globalization.Native.dylib over to the built app bundle and run it on the simulator, themono_arch_create_sdb_trampoline problem is not triggered, and the app runs fine (with the changes locally introduced).

I remember@lambdageek experienced the same problem a while back:#93860 (comment)

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0 libsystem_platform.dylib 0x10ec25828 _platform_memset_pattern16 + 296
1 libmonosgen-2.0.dylib 0x1113f0fa8 mono_arch_create_sdb_trampoline + 76

IIRC it's related to creating executable + writable memory (or failing to do so).

You get the same crash on Mac Catalyst if you enable the sandbox, but don't add the jit entitlement.

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0 libsystem_platform.dylib 0x10ec25828 _platform_memset_pattern16 + 296
1 libmonosgen-2.0.dylib 0x1113f0fa8 mono_arch_create_sdb_trampoline + 76

IIRC it's related to creating executable + writable memory (or failing to do so).

You get the same crash on Mac Catalyst if you enable the sandbox, but don't add the jit entitlement.

If I understand the flow correctly, we shouldn't be getting to themono_arch_create_sdb_trampoline at all.

For the app we generate:

void xamarin_setup_impl (){mono_jit_set_aot_mode (MONO_AOT_MODE_FULL);

which should be invoked from xamarin's main:
https://github.com/xamarin/xamarin-macios/blob/58e382efb7abdb9cf88900bd8e87f27f7e586a51/runtime/monotouch-main.m#L276

that further gets here:

and finally here:

which sets the:mono_ee_features.use_aot_trampolines = TRUE; and should guard against trying to create executable code (sdb trampolines) here:

Will have to set up debug builds of everything I suppose .. :)

/azp run runtime-extra-platforms

This fix probably won't be enough.

I was able to re-produce the original issue (#98941) without Xamarin by trying the Hybrid Globalization testshttps://github.com/dotnet/runtime/blob/release/8.0-staging/src/libraries/System.Globalization/tests/Hybrid/System.Globalization.IOS.Tests.csproj. The error message is the same

System.Globalization.IOS.Tests(42002,0x16df7f000) malloc: *** error for object 0x16df7a695: pointer being freed was not allocatedSystem.Globalization.IOS.Tests(42002,0x16df7f000) malloc: *** set a breakpoint in malloc_error_break to debug

and it also only fails on the newest iOS simulator (17.2 works fine) + it works on the .NET 9 main. However, it doesn't get fixed by using this PR.

Do you know if we possibly export ICU symbols somewhere else in the Mono Runtime?@akoeplinger@mkhamoyan
Or any other idea what could be causing this?

Do you know if we possibly export ICU symbols somewhere else in the Mono Runtime?

You can runnm on Mono's libraries to check which symbols they export.

The code in src/mono/mono/mini/CMakeLists.txtshould have fixed it but yeah check with nm.

I think#98495 has superseded this.

@am11 - that's true for .NET 9, but this change is trying to fix this for .NET 8.

/azp run runtime-extra-platforms