ICU causes crash on iOS 17.4 simulator #98941

rolfbjarne · 2024-02-26T15:53:26Z

Description

App crashes when iOS starts using its own ICU code.

I'm guessing it's because of a symbol clash with Mono's ICU symbols.

Reproduction Steps

Install Xcode 15.3 beta 3.
Create a new iOS project: dotnet new ios
Add this to FinishedLaunching in AppDelegate.cs:

var date = NSDate.Now;
var locale = NSLocale.SystemLocale;
var str = date.DescriptionWithLocale (locale);

Run in an iOS 17.4 simulator

Note: an iOS 17.2 simulator works just fine.

Expected behavior

No crash.

Actual behavior

Crash:

Thread 0 Crashed:: tid_103 Dispatch queue: com.apple.main-thread
0   libsystem_kernel.dylib        	       0x1129293b0 __pthread_kill + 8
1   libsystem_pthread.dylib       	       0x112557130 pthread_kill + 256
2   libsystem_c.dylib             	       0x1801655c0 abort + 104
3   libmonosgen-2.0.dylib         	       0x113316bcc sigabrt_signal_handler.cold.1 + 48
4   libmonosgen-2.0.dylib         	       0x113043a60 sigabrt_signal_handler + 196
5   libsystem_platform.dylib      	       0x1123237e0 _sigtramp + 52
6   libsystem_pthread.dylib       	       0x112557130 pthread_kill + 256
7   libsystem_c.dylib             	       0x1801655c0 abort + 104
8   libsystem_malloc.dylib        	       0x1801e378c malloc_vreport + 900
9   libsystem_malloc.dylib        	       0x1801e3950 malloc_report + 60
10  libsystem_malloc.dylib        	       0x1801d78a0 find_zone_and_free + 456
11  libicucore.A.dylib            	       0x181dbf2a0 icu::Locale::setToBogus() + 48
12  libicucore.A.dylib            	       0x181dc0c44 icu::Locale::operator=(icu::Locale const&) + 36
13  libicucore.A.dylib            	       0x181f2e5f4 icu::number::LocalizedNumberFormatter::LocalizedNumberFormatter(icu::number::impl::MacroProps&&, icu::Locale const&) + 212
14  libicucore.A.dylib            	       0x181eda738 icu::DecimalFormat::touch(UErrorCode&) + 204
15  libicucore.A.dylib            	       0x181edade8 icu::DecimalFormat::DecimalFormat(icu::UnicodeString const&, icu::DecimalFormatSymbols*, UNumberFormatStyle, UErrorCode&) + 328
16  libicucore.A.dylib            	       0x181f491b0 icu::NumberFormat::makeInstance(icu::Locale const&, UNumberFormatStyle, signed char, UErrorCode&) + 1600
17  libicucore.A.dylib            	       0x181f489e8 icu::LocaleCacheKey<icu::SharedNumberFormat>::createObject(void const*, UErrorCode&) const + 84
18  libicucore.A.dylib            	       0x181e6dae0 icu::UnifiedCache::_get(icu::CacheKeyBase const&, icu::SharedObject const*&, void const*, UErrorCode&) const + 140
19  libicucore.A.dylib            	       0x181f495d0 0x181dbd000 + 1623504
20  libicucore.A.dylib            	       0x181f48b10 0x181dbd000 + 1620752
21  libicucore.A.dylib            	       0x181f4864c icu::NumberFormat::createInstance(icu::Locale const&, UNumberFormatStyle, UErrorCode&) + 92
22  libicucore.A.dylib            	       0x181dcacf4 icu::SimpleDateFormat::initialize(icu::Locale const&, UErrorCode&) + 544
23  libicucore.A.dylib            	       0x181dc6030 icu::SimpleDateFormat::construct(icu::DateFormat::EStyle, icu::DateFormat::EStyle, icu::Locale const&, UErrorCode&) + 1952
24  libicucore.A.dylib            	       0x181dc5838 icu::SimpleDateFormat::SimpleDateFormat(icu::DateFormat::EStyle, icu::DateFormat::EStyle, icu::Locale const&, UErrorCode&) + 160
25  libicucore.A.dylib            	       0x181dc5720 icu::DateFormat::create(icu::DateFormat::EStyle, icu::DateFormat::EStyle, icu::Locale const&) + 144
26  libicucore.A.dylib            	       0x181dc5590 udat_open + 392
27  CoreFoundation                	       0x18049f540 __cficu_udat_open + 68
28  CoreFoundation                	       0x1803c3d68 __ResetUDateFormat + 484
29  CoreFoundation                	       0x1803c367c __CreateCFDateFormatter + 320
30  CoreFoundation                	       0x18049b4c0 -[NSDate descriptionWithLocale:] + 96
31  libxamarin-dotnet-debug.dylib 	       0x1129fcb8c xamarin_dyn_objc_msgSend + 160
32  newios                        	       0x109125ab8 wrapper_managed_to_native_ObjCRuntime_Messaging_NativeHandle_objc_msgSend_NativeHandle_intptr_intptr_ObjCRuntime_NativeHandle + 168
33  newios                        	       0x10843723c Foundation_NSDate_DescriptionWithLocale_Foundation_NSLocale + 140 (NSDate.g.cs:173)
34  newios                        	       0x104f5a504 newios_AppDelegate_FinishedLaunching_UIKit_UIApplication_Foundation_NSDictionary + 500 (AppDelegate.cs:17)

Full crash report: https://gist.github.com/rolfbjarne/9fcedeb59d0521c4c9bb931056bba15c

Regression?

Yes. Fortunately it seems to only affect the simulator, and not device.

Known Workarounds

Disable globalization and make the app link mono statically works:

<PropertyGroup>
  <_LibXamarinLinkMode>static</_LibXamarinLinkMode>
  <_LibMonoLinkMode>static</_LibMonoLinkMode>
  <InvariantGlobalization>true</InvariantGlobalization>
</PropertyGroup>
<Target Name="_FixMonoLinkMode" AfterTargets="_MonoReadAvailableComponentsManifest">
  <ItemGroup>
    <_MonoRuntimeComponentLinking Remove="dynamic" />
    <_MonoRuntimeComponentLinking Include="static" RuntimeIdentifier="iossimulator-arm64" />
  </ItemGroup>
</Target>

Configuration

$ dotnet --info
.NET SDK:
 Version:           8.0.100
 Commit:            57efcf1350
 Workload version:  8.0.100-manifests.5638171e

Runtime Environment:
 OS Name:     Mac OS X
 OS Version:  14.4
 OS Platform: Darwin
 RID:         osx-arm64
 Base Path:   /usr/local/share/dotnet/sdk/8.0.100/

.NET workloads installed:
 Workload version: 8.0.100-manifests.5638171e
 [ios]
   Installation Source: SDK 8.0.100
   Manifest Version:    17.2.8022/8.0.100
   Manifest Path:       /usr/local/share/dotnet/sdk-manifests/8.0.100/microsoft.net.sdk.ios/17.2.8022/WorkloadManifest.json
   Install Type:        FileBased


Host:
  Version:      8.0.0
  Architecture: arm64
  Commit:       5535e31a71

.NET SDKs installed:
  8.0.100 [/usr/local/share/dotnet/sdk]

.NET runtimes installed:
  Microsoft.AspNetCore.App 8.0.0 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 8.0.0 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App]

Other architectures found:
  x64   [/usr/local/share/dotnet/x64]
    registered at [/etc/dotnet/install_location_x64]

Environment variables:
  Not set

global.json file:
  Not found

Other information

No response

The text was updated successfully, but these errors were encountered:

rolfbjarne · 2024-02-26T15:54:52Z

CC @steveisok

This completely breaks the simulator for us, so it's rather urgent to get it fixed (and any fixes would have to be backported to .NET 8)

ghost · 2024-02-26T16:03:17Z

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

Issue Details

Description

App crashes when iOS starts using its own ICU code.

I'm guessing it's because of a symbol clash with Mono's ICU symbols.

Reproduction Steps

Install Xcode 15.3 beta 3.
Create a new iOS project: dotnet new ios
Add this to FinishedLaunching in AppDelegate.cs:

var date = NSDate.Now;
var locale = NSLocale.SystemLocale;
var str = date.DescriptionWithLocale (locale);

Run in an iOS 17.4 simulator

Note: an iOS 17.2 simulator works just fine.

Expected behavior

No crash.

Actual behavior

Crash:

Thread 0 Crashed:: tid_103 Dispatch queue: com.apple.main-thread
0   libsystem_kernel.dylib        	       0x1129293b0 __pthread_kill + 8
1   libsystem_pthread.dylib       	       0x112557130 pthread_kill + 256
2   libsystem_c.dylib             	       0x1801655c0 abort + 104
3   libmonosgen-2.0.dylib         	       0x113316bcc sigabrt_signal_handler.cold.1 + 48
4   libmonosgen-2.0.dylib         	       0x113043a60 sigabrt_signal_handler + 196
5   libsystem_platform.dylib      	       0x1123237e0 _sigtramp + 52
6   libsystem_pthread.dylib       	       0x112557130 pthread_kill + 256
7   libsystem_c.dylib             	       0x1801655c0 abort + 104
8   libsystem_malloc.dylib        	       0x1801e378c malloc_vreport + 900
9   libsystem_malloc.dylib        	       0x1801e3950 malloc_report + 60
10  libsystem_malloc.dylib        	       0x1801d78a0 find_zone_and_free + 456
11  libicucore.A.dylib            	       0x181dbf2a0 icu::Locale::setToBogus() + 48
12  libicucore.A.dylib            	       0x181dc0c44 icu::Locale::operator=(icu::Locale const&) + 36
13  libicucore.A.dylib            	       0x181f2e5f4 icu::number::LocalizedNumberFormatter::LocalizedNumberFormatter(icu::number::impl::MacroProps&&, icu::Locale const&) + 212
14  libicucore.A.dylib            	       0x181eda738 icu::DecimalFormat::touch(UErrorCode&) + 204
15  libicucore.A.dylib            	       0x181edade8 icu::DecimalFormat::DecimalFormat(icu::UnicodeString const&, icu::DecimalFormatSymbols*, UNumberFormatStyle, UErrorCode&) + 328
16  libicucore.A.dylib            	       0x181f491b0 icu::NumberFormat::makeInstance(icu::Locale const&, UNumberFormatStyle, signed char, UErrorCode&) + 1600
17  libicucore.A.dylib            	       0x181f489e8 icu::LocaleCacheKey<icu::SharedNumberFormat>::createObject(void const*, UErrorCode&) const + 84
18  libicucore.A.dylib            	       0x181e6dae0 icu::UnifiedCache::_get(icu::CacheKeyBase const&, icu::SharedObject const*&, void const*, UErrorCode&) const + 140
19  libicucore.A.dylib            	       0x181f495d0 0x181dbd000 + 1623504
20  libicucore.A.dylib            	       0x181f48b10 0x181dbd000 + 1620752
21  libicucore.A.dylib            	       0x181f4864c icu::NumberFormat::createInstance(icu::Locale const&, UNumberFormatStyle, UErrorCode&) + 92
22  libicucore.A.dylib            	       0x181dcacf4 icu::SimpleDateFormat::initialize(icu::Locale const&, UErrorCode&) + 544
23  libicucore.A.dylib            	       0x181dc6030 icu::SimpleDateFormat::construct(icu::DateFormat::EStyle, icu::DateFormat::EStyle, icu::Locale const&, UErrorCode&) + 1952
24  libicucore.A.dylib            	       0x181dc5838 icu::SimpleDateFormat::SimpleDateFormat(icu::DateFormat::EStyle, icu::DateFormat::EStyle, icu::Locale const&, UErrorCode&) + 160
25  libicucore.A.dylib            	       0x181dc5720 icu::DateFormat::create(icu::DateFormat::EStyle, icu::DateFormat::EStyle, icu::Locale const&) + 144
26  libicucore.A.dylib            	       0x181dc5590 udat_open + 392
27  CoreFoundation                	       0x18049f540 __cficu_udat_open + 68
28  CoreFoundation                	       0x1803c3d68 __ResetUDateFormat + 484
29  CoreFoundation                	       0x1803c367c __CreateCFDateFormatter + 320
30  CoreFoundation                	       0x18049b4c0 -[NSDate descriptionWithLocale:] + 96
31  libxamarin-dotnet-debug.dylib 	       0x1129fcb8c xamarin_dyn_objc_msgSend + 160
32  newios                        	       0x109125ab8 wrapper_managed_to_native_ObjCRuntime_Messaging_NativeHandle_objc_msgSend_NativeHandle_intptr_intptr_ObjCRuntime_NativeHandle + 168
33  newios                        	       0x10843723c Foundation_NSDate_DescriptionWithLocale_Foundation_NSLocale + 140 (NSDate.g.cs:173)
34  newios                        	       0x104f5a504 newios_AppDelegate_FinishedLaunching_UIKit_UIApplication_Foundation_NSDictionary + 500 (AppDelegate.cs:17)

Full crash report: https://gist.github.com/rolfbjarne/9fcedeb59d0521c4c9bb931056bba15c

Regression?

Yes. Fortunately it seems to only affect the simulator, and not device.

Known Workarounds

Disable globalization and make the app link mono statically works:

<PropertyGroup>
  <_LibXamarinLinkMode>static</_LibXamarinLinkMode>
  <_LibMonoLinkMode>static</_LibMonoLinkMode>
  <InvariantGlobalization>true</InvariantGlobalization>
</PropertyGroup>
<Target Name="_FixMonoLinkMode" AfterTargets="_MonoReadAvailableComponentsManifest">
  <ItemGroup>
    <_MonoRuntimeComponentLinking Remove="dynamic" />
    <_MonoRuntimeComponentLinking Include="static" RuntimeIdentifier="iossimulator-arm64" />
  </ItemGroup>
</Target>

Configuration

$ dotnet --info
.NET SDK:
 Version:           8.0.100
 Commit:            57efcf1350
 Workload version:  8.0.100-manifests.5638171e

Runtime Environment:
 OS Name:     Mac OS X
 OS Version:  14.4
 OS Platform: Darwin
 RID:         osx-arm64
 Base Path:   /usr/local/share/dotnet/sdk/8.0.100/

.NET workloads installed:
 Workload version: 8.0.100-manifests.5638171e
 [ios]
   Installation Source: SDK 8.0.100
   Manifest Version:    17.2.8022/8.0.100
   Manifest Path:       /usr/local/share/dotnet/sdk-manifests/8.0.100/microsoft.net.sdk.ios/17.2.8022/WorkloadManifest.json
   Install Type:        FileBased


Host:
  Version:      8.0.0
  Architecture: arm64
  Commit:       5535e31a71

.NET SDKs installed:
  8.0.100 [/usr/local/share/dotnet/sdk]

.NET runtimes installed:
  Microsoft.AspNetCore.App 8.0.0 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 8.0.0 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App]

Other architectures found:
  x64   [/usr/local/share/dotnet/x64]
    registered at [/etc/dotnet/install_location_x64]

Environment variables:
  Not set

global.json file:
  Not found

Other information

No response

Author:	rolfbjarne
Assignees:	-
Labels:	`area-System.Globalization`, `untriaged`, `os-ios`
Milestone:	-

tarekgh · 2024-02-26T16:26:35Z

CC @akoeplinger

vitek-karas · 2024-02-26T17:16:26Z

/cc @matouskozak @ivanpovazan

lewing · 2024-02-27T16:16:37Z

@rolfbjarne @tarekgh @vitek-karas this is net8 so it isn't using hybrid globalization

steveisok · 2024-02-27T16:39:52Z

CC @steveisok

This completely breaks the simulator for us, so it's rather urgent to get it fixed (and any fixes would have to be backported to .NET 8)

Weird, I'm mentioned, but got no notification of this. @rolfbjarne confirming this is off of a .net 8 runtime?

tarekgh · 2024-02-27T16:40:50Z

@lewing I didn't claim it is from hybird globalization 😄

looking at the stack

24  libicucore.A.dylib            	       0x181dc5838 icu::SimpleDateFormat::SimpleDateFormat(icu::DateFormat::EStyle, icu::DateFormat::EStyle, icu::Locale const&, UErrorCode&) + 160
25  libicucore.A.dylib            	       0x181dc5720 icu::DateFormat::create(icu::DateFormat::EStyle, icu::DateFormat::EStyle, icu::Locale const&) + 144
26  libicucore.A.dylib            	       0x181dc5590 udat_open + 392
27  CoreFoundation                	       0x18049f540 __cficu_udat_open + 68
28  CoreFoundation                	       0x1803c3d68 __ResetUDateFormat + 484
29  CoreFoundation                	       0x1803c367c __CreateCFDateFormatter + 320
30  CoreFoundation                	       0x18049b4c0 -[NSDate descriptionWithLocale:] + 96
31  libxamarin-dotnet-debug.dylib 	       0x1129fcb8c xamarin_dyn_objc_msgSend + 160

It is the calls to the CoreFoundation. I believe @steveisok is familiar with that stack. Something in the code

runtime/src/native/libs/System.Globalization.Native/pal_locale.m

Line 96 in 62304a6

    
           const char* GlobalizationNative_GetLocaleInfoStringNative(const char* localeName, LocaleStringData localeStringData)

mkhamoyan · 2024-02-27T16:52:58Z

looking at the stack

24  libicucore.A.dylib            	       0x181dc5838 icu::SimpleDateFormat::SimpleDateFormat(icu::DateFormat::EStyle, icu::DateFormat::EStyle, icu::Locale const&, UErrorCode&) + 160
25  libicucore.A.dylib            	       0x181dc5720 icu::DateFormat::create(icu::DateFormat::EStyle, icu::DateFormat::EStyle, icu::Locale const&) + 144
26  libicucore.A.dylib            	       0x181dc5590 udat_open + 392
27  CoreFoundation                	       0x18049f540 __cficu_udat_open + 68
28  CoreFoundation                	       0x1803c3d68 __ResetUDateFormat + 484
29  CoreFoundation                	       0x1803c367c __CreateCFDateFormatter + 320
30  CoreFoundation                	       0x18049b4c0 -[NSDate descriptionWithLocale:] + 96
31  libxamarin-dotnet-debug.dylib 	       0x1129fcb8c xamarin_dyn_objc_msgSend + 160

It is the calls to the CoreFoundation. I believe @steveisok is familiar with that stack. Something in the code

Calls to CoreFoundation are because of this block in AppDelegate.cs.

var date = NSDate.Now;
var locale = NSLocale.SystemLocale;
var str = date.DescriptionWithLocale (locale);

Most of the functions from runtime/src/native/libs/System.Globalization.Native/pal_locale.m will not be used in described scenario , only some of them like

runtime/src/native/libs/System.Globalization.Native/pal_locale.m

Line 17 in 62304a6

char* DetectDefaultAppleLocaleName(void)

but from stacktrace these functions are not called.

rolfbjarne · 2024-02-27T17:08:05Z

CC @steveisok
This completely breaks the simulator for us, so it's rather urgent to get it fixed (and any fixes would have to be backported to .NET 8)

Weird, I'm mentioned, but got no notification of this. @rolfbjarne confirming this is off of a .net 8 runtime?

Confirmed, this is with stable versions of everything (except Xcode).

steveisok · 2024-02-27T17:16:44Z

This is strange. This seems to be bypassing our globalization PAL. If true, that's unexpected and likely some kind of clash as @rolfbjarne suggested.

@rolfbjarne am I correct in seeing that the objc bindings are bypassing runtime?

rolfbjarne · 2024-02-28T06:21:21Z

This is strange. This seems to be bypassing our globalization PAL. If true, that's unexpected and likely some kind of clash as @rolfbjarne suggested.

@rolfbjarne am I correct in seeing that the objc bindings are bypassing runtime?

I'm not really sure what you mean. Our Objective-C bindings call iOS APIs, in this case in particular, [NSDate descriptionWithLocale:]. I see no reason for NSDate to call anything in the runtime's globalization PAL.

steveisok · 2024-02-28T12:16:27Z

I'm not really sure what you mean. Our Objective-C bindings call iOS APIs, in this case in particular, [NSDate descriptionWithLocale:]. I see no reason for NSDate to call anything in the runtime's globalization PAL.

That's good enough. You're confirming what I thought. I'm not sure exactly what to do here. I wonder if it worked previously by luck? Perhaps the icu version on that simulator has changed?

@akoeplinger since you've seen icu clashes like this before, any thoughts?

dalexsoto · 2024-02-28T12:36:39Z

Xcode 15.3 RC 1 is out and unfortunately we can still repro the issue

ivanpovazan · 2024-02-28T13:12:54Z

Perhaps the icu version on that simulator has changed?

That might be it. Looking at the difference between versions:

diff \
/Applications/Xcode_15.3.0.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator.sdk/usr/lib/libicucore.A.tbd \
/Applications/Xcode_15.2.0.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator.sdk/usr/lib/libicucore.A.tbd

shows:

< current-version: 74.1
---
> current-version: 72.1

On the other hand, our latest Microsoft.NETCore.Runtime.ICU.Transport 9.0.0-preview.3.24123.1
seems to include: ICU_version = 68.2.0.9

akoeplinger · 2024-02-28T14:47:19Z

This is pretty weird, according to the stacktrace this called into the system ICU libicucore.A.dylib since we don't ship a .dylib for icu.

If I had to guess it's maybe using our uprv_free in https://github.com/unicode-org/icu/blob/2d029329c82c7792b985024b2bdab5fc7278fbc8/icu4c/source/common/locid.cpp#L2022-L2039 instead of theirs?

One workaround that I think might be acceptable risk-wise is to rename the exported symbols to have e.g. a dotnet_ prefix. There is some functionality in urename.h that could be used.

rolfbjarne · 2024-02-29T16:23:36Z

One workaround that I think might be acceptable risk-wise is to rename the exported symbols to have e.g. a dotnet_ prefix. There is some functionality in urename.h that could be used.

We did this numerous times in Mono.

rolfbjarne · 2024-03-01T10:54:13Z

@steveisok .NET 9 seems to be working fine

dalexsoto · 2024-03-04T18:03:39Z

@steveisok / @vitek-karas any news on this issue?

steveisok · 2024-03-04T18:27:09Z

One workaround that I think might be acceptable risk-wise is to rename the exported symbols to have e.g. a dotnet_ prefix. There is some functionality in urename.h that could be used.

@dalexsoto looks like we're going to try this approach. Unsure of an ETA at this time.

ivanpovazan · 2024-03-05T13:39:04Z

I managed to repro and @rolfbjarne thank you for providing the workaround:

<PropertyGroup>
  <_LibXamarinLinkMode>static</_LibXamarinLinkMode>
  <_LibMonoLinkMode>static</_LibMonoLinkMode>
  <InvariantGlobalization>true</InvariantGlobalization>
</PropertyGroup>
<Target Name="_FixMonoLinkMode" AfterTargets="_MonoReadAvailableComponentsManifest">
  <ItemGroup>
    <_MonoRuntimeComponentLinking Remove="dynamic" />
    <_MonoRuntimeComponentLinking Include="static" RuntimeIdentifier="iossimulator-arm64" />
  </ItemGroup>
</Target>

Although the app seems to work with just forcing static linking (we don't have to additionally disable globalization via <InvariantGlobalization>true</InvariantGlobalization> as a workaround) which also hints there is a problem with the exported symbols

ivanpovazan · 2024-04-23T11:03:54Z

The fix unfortunately did not reach 8.0.4.
We will update this issue and let you know, once we verify that the fix is part of the upcoming release and that it solves the reported problem.

divil5000 · 2024-04-29T11:50:52Z

Is there a recommended workaround if we are using net8-iOS? It's when running on Mac that our users are hitting crashes.

vitek-karas · 2024-04-30T10:07:41Z

@divil5000 did you try the workaround posted by @ivanpovazan ? #98941 (comment)

divil5000 · 2024-04-30T12:20:16Z

Actually no. I've just tried a release build of our iOS software on MacOS now we are building under net8-ios, and that build appears to work without the workaround. Is that expected? I've verified that the latest public version from the App Store (build under net7-ios) crashes without fail when showing a date picker.

matouskozak · 2024-04-30T15:45:58Z

I've just tried a release build of our iOS software on MacOS now we are building under net8-ios, and that build appears to work without the workaround.

Is this related to the previously described scenario #98941 (comment)? If so, It is not clear to me if the app is build for iOSSimulator (net8.0-ios) or device (ios-arm64/x64). Could you please share some steps how to reproduce the setup localy.

I've verified that the latest public version from the App Store (build under net7-ios) crashes without fail when showing a date picker.

Is it possible that the net7 version of the app is build for simulator by default whereas net8 for device? That would explain why one fails and the other doesn't.

divil5000 · 2024-04-30T16:41:09Z

We actually never build for simulator, at least not knowingly. Not during development, and it never even occurred to me that one could build for simulator and deploy such a build via the App Store. However, in our project file we just have the TargetFramework set as net8.0-ios. From what you wrote above, it looks like we should have a different TargetFramework set, but I don't recall seeing that documented when we moved from Xamarin to net7. Are we doing something wrong?

But yes, that comment of mine is the crash log from our currently-deployed public release.

matouskozak · 2024-04-30T16:50:49Z

We actually never build for simulator, at least not knowingly. Not during development, and it never even occurred to me that one could build for simulator and deploy such a build via the App Store. However, in our project file we just have the TargetFramework set as net8.0-ios. From what you wrote above, it looks like we should have a different TargetFramework set, but I don't recall seeing that documented when we moved from Xamarin to net7. Are we doing something wrong?

But yes, that comment of mine is the crash log from our currently-deployed public release.

@rolfbjarne do you have any insight into what is the default build configuration in this scenario for net7 and net8 Xamarin?

rolfbjarne · 2024-04-30T17:02:46Z

We actually never build for simulator, at least not knowingly. Not during development, and it never even occurred to me that one could build for simulator and deploy such a build via the App Store. However, in our project file we just have the TargetFramework set as net8.0-ios. From what you wrote above, it looks like we should have a different TargetFramework set, but I don't recall seeing that documented when we moved from Xamarin to net7. Are we doing something wrong?
But yes, that comment of mine is the crash log from our currently-deployed public release.

@rolfbjarne do you have any insight into what is the default build configuration in this scenario for net7 and net8 Xamarin?

It's not possible to build for the simulator and publish the result to the App Store, the App Store will not allow such uploads.

As far as I can remember, there were no differences in the default build configuration for device builds between .NET 7 and .NET 8.

Actually no. I've just tried a release build of our iOS software on MacOS now we are building under net8-ios, and that build appears to work without the workaround. Is that expected?

Yes, that's expected. We've never seen this issue on an actual iOS device, only on an iOS simulator, iOS device build running on macOS hardware, and Mac Catalyst.

I've verified that the latest public version from the App Store (build under net7-ios) crashes without fail when showing a date picker.

Do you have a crash report?

divil5000 · 2024-04-30T17:06:40Z

Ok. My scenario is the iOS device build (built with net7-ios) running on macOS hardware. Yes I have a crash report, it's the one I posted further up this thread (#98941 (comment)). What I am reporting today is that after rebuilding with net8-ios, the crash appears not to happen (though this hasn't been through the App Store at this point).

rolfbjarne · 2024-05-01T15:20:33Z

Ok. My scenario is the iOS device build (built with net7-ios) running on macOS hardware. Yes I have a crash report, it's the one I posted further up this thread (#98941 (comment)). What I am reporting today is that after rebuilding with net8-ios, the crash appears not to happen (though this hasn't been through the App Store at this point).

Ah I see, that's somewhat unexpected, although it would explain why we haven't seen many people run into the bug on macOS hardware, if it only happens when building with .NET 7.

In any case, if it works, then that's good.

TheXenocide · 2024-05-07T19:29:06Z

I haven't dug into the details here too closely but it looks like I was hitting this issue as well. The workaround worked for me, but the InvariantGlobalization caused my app to get an exception when accessing CultureInfo.CurrentCulture.Name. Commenting out that line seems to work well enough for me for now (haven't tried any localization testing, but the workaround is still letting me use latest XCode/Simulators).

matouskozak · 2024-05-07T19:50:13Z

I haven't dug into the details here too closely but it looks like I was hitting this issue as well. The workaround worked for me, but the InvariantGlobalization caused my app to get an exception when accessing CultureInfo.CurrentCulture.Name. Commenting out that line seems to work well enough for me for now (haven't tried any localization testing, but the workaround is still letting me use latest XCode/Simulators).

You are right, forcing InvariantGlobalization shouldn't be necessary, only linking Mono statically yes. See #98941 (comment). Perhaps we should update the top-level workaround.

matouskozak · 2024-05-15T06:43:56Z

The .NET 8.0.5 servicing is out and the fix is in. I verified locally that the sample app with

var date = NSDate.Now;
var locale = NSLocale.SystemLocale;
var str = date.DescriptionWithLocale (locale);

no longer crashes on iOS 17.4 simulator. @rolfbjarne could you verify from Xamarin side that everything works as expected?

velocitysystems · 2024-05-28T12:21:24Z

@matouskozak @rolfbjarne Has 8.0.5 been published on NuGet to be available via dotnet workload update?
I have tried several times updating and reinstalling but all I can get is:

Installed Workload Id      Manifest Version      Installation Source
--------------------------------------------------------------------
maui                       8.0.21/8.0.100        SDK 8.0.300

According to Release Versions 8.0.40 should be the latest.

matouskozak · 2024-05-28T12:48:12Z

@matouskozak @rolfbjarne Has 8.0.5 been published on NuGet to be available via dotnet workload update? I have tried several times updating and reinstalling but all I can get is:
Installed Workload Id      Manifest Version      Installation Source
--------------------------------------------------------------------
maui                       8.0.21/8.0.100        SDK 8.0.300     
According to Release Versions 8.0.40 should be the latest.

The .NET 8.0.300 SDK should contain the .NET 8.0.5 Runtime servicing release. You can check it out at https://dotnet.microsoft.com/en-us/download/dotnet/8.0. Are you still encountering this issue with .NET 8.0.300 SDK?

velocitysystems · 2024-05-28T12:52:48Z

Thanks @matouskozak. I can confirm I have .NET 8.0.300 SDK installed:

dotnet --list-sdks
6.0.202 [/usr/local/share/dotnet/sdk]
7.0.315 [/usr/local/share/dotnet/sdk]
8.0.300 [/usr/local/share/dotnet/sdk]

dotnet --version
8.0.300

Yes, I'm still seeing this issue when building with 8.0.300. This would seem to be expected though since the installed workload is 8.0.21 which according to the Release Versions page is only compatible with Xcode 15.2. How do I force the workload to update to the correct version? Is this an issue with the dotnet workload tool or package source?

OS is macOS Sonoma 14.5 with Xcode 15.4.

Kylar182 · 2024-05-28T13:00:18Z

Thanks @matouskozak. I can confirm I have .NET 8.0.300 SDK installed:
dotnet --list-sdks
6.0.202 [/usr/local/share/dotnet/sdk]
7.0.315 [/usr/local/share/dotnet/sdk]
8.0.300 [/usr/local/share/dotnet/sdk]

dotnet --version
8.0.300
Yes, I'm still seeing this issue when building with 8.0.300. This would seem to be expected though since the installed workload is 8.0.21 which according to the Release Versions page is only compatible with Xcode 15.2. How do I force the workload to update to the correct version? Is this an issue with the dotnet workload tool or package source?

I removed the original temp fix code and just updated all the Nuget packages (including MAUI Packages) and it worked. I saw the same issue with the MAUI packages showing 8.0.21 / 8.040 but it didn't show up today. I put it into production this morning after testing the last week.

matouskozak · 2024-05-29T09:52:25Z

Thanks @matouskozak. I can confirm I have .NET 8.0.300 SDK installed:
dotnet --list-sdks
6.0.202 [/usr/local/share/dotnet/sdk]
7.0.315 [/usr/local/share/dotnet/sdk]
8.0.300 [/usr/local/share/dotnet/sdk]

dotnet --version
8.0.300
Yes, I'm still seeing this issue when building with 8.0.300. This would seem to be expected though since the installed workload is 8.0.21 which according to the Release Versions page is only compatible with Xcode 15.2. How do I force the workload to update to the correct version? Is this an issue with the dotnet workload tool or package source?

OS is macOS Sonoma 14.5 with Xcode 15.4.

I think it is possible that your MAUI app is still pulling the old .NET runtime release (you could check that by looking into the binlog file). If that is the case, I would try clearing the nuget cache and re-running the dotnet workload update.

ghost added the untriaged New issue has not been triaged by the area owner label Feb 26, 2024

dotnet-issue-labeler bot added the needs-area-label An area label is needed to ensure this gets routed to the appropriate area owners label Feb 26, 2024

vcsjones added area-System.Globalization os-ios Apple iOS and removed needs-area-label An area label is needed to ensure this gets routed to the appropriate area owners labels Feb 26, 2024

lewing assigned mkhamoyan Feb 26, 2024

lewing added this to the 9.0.0 milestone Feb 26, 2024

ghost removed the untriaged New issue has not been triaged by the area owner label Feb 26, 2024

lewing unassigned mkhamoyan Feb 27, 2024

MichalPetryka mentioned this issue Feb 29, 2024

DateTime format issue with Alpine 3.19 dotnet/dotnet-docker#5234

Closed

jeromelaban mentioned this issue Apr 24, 2024

[Epic] Opened Microsoft issues tracking unoplatform/uno#982

Open

philipphofmann mentioned this issue Apr 25, 2024

Sentry.MAUI crashing when launching getsentry/sentry-dotnet#3235

Closed

maxkatz6 mentioned this issue May 1, 2024

iOS crashes on iossimulator-arm64 with OpenGLES rendering AvaloniaUI/Avalonia#14933

Closed

bijington mentioned this issue May 13, 2024

[BUG] On iOS 17.4, the toolkit:MediaElement crashes, whereas it still functions properly on 17.2. CommunityToolkit/Maui#1876

Closed

2 tasks

matouskozak closed this as completed May 15, 2024

bitsandfoxes mentioned this issue May 15, 2024

Sentry.MAUI crashing when launching for iOS 17.4 Simulator(17.0/17.2 works) getsentry/sentry-dotnet#3252

Closed

akoeplinger mentioned this issue May 23, 2024

Migrate to zlib-ng, part 2: consume it in runtime #102403

Merged

15 tasks

ztl8702 mentioned this issue May 28, 2024

iOS Simulator 17.4 "native crash" on Template Solution AvaloniaUI/Avalonia#15135

Closed

rolfbjarne mentioned this issue May 30, 2024

Simple net8.0-ios app - native crash at startup (Avalonia XPAT project) xamarin/xamarin-macios#20657

Closed

kiddkaffeine mentioned this issue Jun 2, 2024

Use of certain GameKit APIs cause crash when running an iOS app on Mac #102964

Closed

rolfbjarne mentioned this issue Jun 11, 2024

Enumerating contacts retrieved by GetAllAsync traps dotnet/maui#22957

Closed

github-actions bot locked and limited conversation to collaborators Jun 29, 2024

ICU causes crash on iOS 17.4 simulator #98941

ICU causes crash on iOS 17.4 simulator #98941

Comments

rolfbjarne commented Feb 26, 2024

Description

Reproduction Steps

Expected behavior

Actual behavior

Regression?

Known Workarounds

Configuration

Other information

rolfbjarne commented Feb 26, 2024

ghost commented Feb 26, 2024

Description

Reproduction Steps

Expected behavior

Actual behavior

Regression?

Known Workarounds

Configuration

Other information

tarekgh commented Feb 26, 2024

vitek-karas commented Feb 26, 2024

lewing commented Feb 27, 2024

steveisok commented Feb 27, 2024

tarekgh commented Feb 27, 2024

mkhamoyan commented Feb 27, 2024 • edited Loading

rolfbjarne commented Feb 27, 2024

steveisok commented Feb 27, 2024

rolfbjarne commented Feb 28, 2024

steveisok commented Feb 28, 2024

dalexsoto commented Feb 28, 2024

ivanpovazan commented Feb 28, 2024

akoeplinger commented Feb 28, 2024 • edited Loading

rolfbjarne commented Feb 29, 2024

rolfbjarne commented Mar 1, 2024

dalexsoto commented Mar 4, 2024

steveisok commented Mar 4, 2024 • edited Loading

ivanpovazan commented Mar 5, 2024

ivanpovazan commented Apr 23, 2024

divil5000 commented Apr 29, 2024

vitek-karas commented Apr 30, 2024

divil5000 commented Apr 30, 2024

matouskozak commented Apr 30, 2024 • edited Loading

divil5000 commented Apr 30, 2024

matouskozak commented Apr 30, 2024 • edited Loading

rolfbjarne commented Apr 30, 2024

divil5000 commented Apr 30, 2024

rolfbjarne commented May 1, 2024

TheXenocide commented May 7, 2024

matouskozak commented May 7, 2024 • edited Loading

matouskozak commented May 15, 2024 • edited Loading

velocitysystems commented May 28, 2024 • edited Loading

matouskozak commented May 28, 2024 • edited Loading

velocitysystems commented May 28, 2024 • edited Loading

Kylar182 commented May 28, 2024

matouskozak commented May 29, 2024

mkhamoyan commented Feb 27, 2024 •

edited

Loading

akoeplinger commented Feb 28, 2024 •

edited

Loading

steveisok commented Mar 4, 2024 •

edited

Loading

matouskozak commented Apr 30, 2024 •

edited

Loading

matouskozak commented Apr 30, 2024 •

edited

Loading

matouskozak commented May 7, 2024 •

edited

Loading

matouskozak commented May 15, 2024 •

edited

Loading

velocitysystems commented May 28, 2024 •

edited

Loading

matouskozak commented May 28, 2024 •

edited

Loading

velocitysystems commented May 28, 2024 •

edited

Loading