search

dotnet / runtime

.NET is a cross-platform runtime for cloud, mobile, desktop, and IoT apps.
https://docs.microsoft.com/dotnet/core/
MIT License
15.14k stars 4.71k forks source link

ICU causes crash on iOS 17.4 simulator #98941

Closed rolfbjarne closed 5 months ago

rolfbjarne commented 7 months ago

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

  1. Install Xcode 15.3 beta 3.
  2. Create a new iOS project: dotnet new ios
  3. Add this to FinishedLaunching in AppDelegate.cs:
var date = NSDate.Now;
var locale = NSLocale.SystemLocale;
var str = date.DescriptionWithLocale (locale);
  1. 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

MaxWroe commented 6 months ago

We are also seeing similar with our iOS app deployed in production on macOS 14.4. Stack trace below. Do you think it's the same thing @rolfbjarne ? Interestingly, it's happening when we try to show a date/time picker UI element.

Thread 0 Crashed:: tid_103 Dispatch queue: com.apple.main-thread 0 libsystem_kernel.dylib 0x189d4aa60 pthread_kill + 8 1 libsystem_pthread.dylib 0x189d82c20 pthread_kill + 288 2 libsystem_c.dylib 0x189c8fa20 abort + 180 3 AppName 0x1067e5748 0x104eb4000 + 26416968 4 AppName 0x1067839b0 0x104eb4000 + 26016176 5 libsystem_platform.dylib 0x189db3584 _sigtramp + 56 6 libsystem_pthread.dylib 0x189d82c20 pthread_kill + 288 7 libsystem_c.dylib 0x189c8fa20 abort + 180 8 libsystem_malloc.dylib 0x189b9faa8 malloc_vreport + 896 9 libsystem_malloc.dylib 0x189ba3114 malloc_report + 64 10 libsystem_malloc.dylib 0x189bbd494 find_zone_and_free + 528 11 libicucore.A.dylib 0x18cef7edc icu::Locale::setToBogus() + 52 12 libicucore.A.dylib 0x18cef8240 icu::Locale::operator=(icu::Locale const&) + 40 13 libicucore.A.dylib 0x18d05dd08 icu::number::LocalizedNumberFormatter::LocalizedNumberFormatter(icu::number::impl::MacroProps&&, icu::Locale const&) + 216 14 libicucore.A.dylib 0x18cfff7c0 icu::DecimalFormat::touch(UErrorCode&) + 240 15 libicucore.A.dylib 0x18d000024 icu::DecimalFormat::DecimalFormat(icu::UnicodeString const&, icu::DecimalFormatSymbols, UNumberFormatStyle, UErrorCode&) + 380 16 libicucore.A.dylib 0x18d07b718 icu::NumberFormat::makeInstance(icu::Locale const&, UNumberFormatStyle, signed char, UErrorCode&) + 1668 17 libicucore.A.dylib 0x18d07aec8 icu::LocaleCacheKeyicu::SharedNumberFormat::createObject(void const, UErrorCode&) const + 88 18 libicucore.A.dylib 0x18cf82d08 icu::UnifiedCache::_get(icu::CacheKeyBase const&, icu::SharedObject const&, void const, UErrorCode&) const + 168 19 libicucore.A.dylib 0x18d07bcd8 0x18ced8000 + 1719512 20 libicucore.A.dylib 0x18d07b034 0x18ced8000 + 1716276 21 libicucore.A.dylib 0x18d07a930 icu::NumberFormat::createInstance(icu::Locale const&, UNumberFormatStyle, UErrorCode&) + 112 22 libicucore.A.dylib 0x18d0ca4bc icu::SimpleDateFormat::initialize(icu::Locale const&, UErrorCode&) + 572 23 libicucore.A.dylib 0x18d0c9f04 icu::SimpleDateFormat::construct(icu::DateFormat::EStyle, icu::DateFormat::EStyle, icu::Locale const&, UErrorCode&) + 2024 24 libicucore.A.dylib 0x18d0cb234 icu::SimpleDateFormat::SimpleDateFormat(icu::DateFormat::EStyle, icu::DateFormat::EStyle, icu::Locale const&, UErrorCode&) + 252 25 libicucore.A.dylib 0x18cff2254 icu::DateFormat::create(icu::DateFormat::EStyle, icu::DateFormat::EStyle, icu::Locale const&) + 172 26 libicucore.A.dylib 0x18d101fac udat_open + 396 27 CoreFoundation 0x189e9ee78 cficu_udat_open + 72 28 CoreFoundation 0x189e9e22c ResetUDateFormat + 516 29 CoreFoundation 0x189e9dffc __CreateCFDateFormatter + 324 30 Foundation 0x18afb53f4 -[NSDateFormatter _regenerateFormatter] + 264 31 Foundation 0x18afb5208 -[NSDateFormatter stringForObjectValue:] + 280 32 AppKit 0x18d92ce18 constructReferenceString_block_invoke + 352 33 AppKit 0x18d92cbac enumerateFormatSpecifiers + 624 34 AppKit 0x18dbf3a10 -[NSDatePickerCell(NSTextFieldWithStepperDatePickerInternal) _makeSubfieldsWithHandler:] + 332 35 AppKit 0x18d92c83c -[NSDatePickerCell(NSTextFieldWithStepperDatePickerInternal) _createSubfields] + 156 36 AppKit 0x18d92c2f8 -[NSDatePickerCell initTextCell:] + 292 37 AppKit 0x18d6de8bc -[NSControl initWithFrame:] + 128 38 AppKit 0x18d92c194 -[NSDatePicker initWithFrame:] + 48 39 UIKitMacHelper 0x1a30fc9bc -[UINSShadowDatePicker createBackingDatePickerIfNecessary] + 52 40 UIKitCore 0x1ba359cc8 -[_UIDatePickerMacCompactView setUpTextFieldsToMatchData:] + 56 41 UIKitCore 0x1ba358aa4 -[_UIDatePickerMacCompactView setData:] + 68 42 UIKitCore 0x1b9ea4ea8 -[UIDatePicker _installPickerView:updatingSize:] + 160 43 UIKitCore 0x1b9ea41f4 -[UIDatePicker initWithFrame:] + 340 44 AppName 0x1064ee0c0 0x104eb4000 + 23306432 45 AppName 0x105207338 0x104eb4000 + 3486520 46 AppName 0x106449968 0x104eb4000 + 22632808 47 AppName 0x106756870 0x104eb4000 + 25831536 48 AppName 0x1066a76d4 0x104eb4000 + 25114324 49 AppName 0x1066a9498 0x104eb4000 + 25121944 50 AppName 0x1067c27b8 0x104eb4000 + 26273720 51 AppName 0x1067c9890 0x104eb4000 + 26302608 52 UIKitCore 0x1ba076da0 -[UITableView _selectRowAtIndexPath:animated:scrollPosition:notifyDelegate:isCellMultiSelect:deselectPrevious:performCustomSelectionAction:] + 1232 53 UIKitCore 0x1ba0770e8 -[UITableView _userSelectRowAtPendingSelectionIndexPath:animatedSelection:] + 296 54 UIKitCore 0x1b93ef52c -[UITableView _userSelectRowAtPendingSelectionIndexPath:] + 216 55 UIKitCore 0x1ba2ca3fc -[_UIAfterCACommitBlock run] + 72 56 UIKitCore 0x1ba2ca840 -[_UIAfterCACommitQueue flush] + 152 57 UIKitCore 0x1b91ee674 _runAfterCACommitDeferredBlocks + 496 58 UIKitCore 0x1b91ee400 _cleanUpAfterCAFlushAndRunDeferredBlocks + 100 59 UIKitCore 0x1b91ee324 _afterCACommitHandler + 32 60 CoreFoundation 0x189e61254 CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION + 36 61 CoreFoundation 0x189e61140 __CFRunLoopDoObservers + 536 62 CoreFoundation 0x189e5fe58 CFRunLoopRunSpecific + 684 63 HIToolbox 0x1945fb000 RunCurrentEventLoopInMode + 292 64 HIToolbox 0x1945fac90 ReceiveNextEventCommon + 220 65 HIToolbox 0x1945fab94 _BlockUntilNextEventMatchingListInModeWithFilter + 76 66 AppKit 0x18d6b8970 _DPSNextEvent + 660 67 AppKit 0x18deaadec -[NSApplication(NSEventRouting) _nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 700 68 AppKit 0x18d6abcb8 -[NSApplication run] + 476 69 AppKit 0x18d682f54 NSApplicationMain + 880 70 AppKit 0x18d8d5610 _NSApplicationMainWithInfoDictionary + 24 71 UIKitMacHelper 0x1a30f10dc UINSApplicationMain + 972 72 UIKitCore 0x1b91dd9b4 UIApplicationMain + 148 73 AppName 0x1064e2790 xamarin_UIApplicationMain + 24 74 AppName 0x105205650 0x104eb4000 + 3479120 75 AppName 0x106432ee0 0x104eb4000 + 22540000 76 AppName 0x106756870 0x104eb4000 + 25831536 77 AppName 0x1066a5e24 0x104eb4000 + 25108004 78 AppName 0x1066ac6cc 0x104eb4000 + 25134796 79 AppName 0x10675b8dc 0x104eb4000 + 25852124 80 AppName 0x1064ed890 0x104eb4000 + 23304336 81 AppName 0x1067c1d20 0x104eb4000 + 26271008 82 dyld 0x1899fa0e0 start + 2360

Our users are facing an identical issue for our MAUI / Mac Catalyst app, impacting production and causing our app to crash immediately on start-up. Do we have any ETA on a fix or confirmation that any of the suggested workarounds fix the issue for Mac Catalyst?

ivanpovazan commented 6 months ago

Our users are facing an identical issue for our MAUI / Mac Catalyst app, impacting production and causing our app to crash immediately on start-up. Do we have any ETA on a fix or confirmation that any of the suggested workarounds fix the issue for Mac Catalyst?

which dotnet version is the problematic app targeting?

MaxWroe commented 6 months ago

Our users are facing an identical issue for our MAUI / Mac Catalyst app, impacting production and causing our app to crash immediately on start-up. Do we have any ETA on a fix or confirmation that any of the suggested workarounds fix the issue for Mac Catalyst?

which dotnet version is the problematic app targeting?

Our app currently targets .Net 7

ivanpovazan commented 6 months ago

@MaxWroe

Regarding .NET8 - the next servicing release - should include the fix for .NET8

Regarding .NET7 - The workaround I posted above should work also in your scenario with some minimal changes. Forcing static linking mode is not needed as it is the default mode when building maccatalyst apps, so the workaround when targeting net7.0-maccatalyst would be:

<Target Name="_OverwriteReferencesLinkerFlags" BeforeTargets="_LinkNativeExecutable">
    <!-- Remove the `-u` prefix from `_ReferencesLinkerFlags` so we can give the output file to the platform linker -->
    <!-- NOTE: This step is actually also done after LinkNativeCode task, but we cannot intercept it differently -->
    <WriteLinesToFile SessionId="$(BuildSessionId)" File="$(_MtouchSymbolsList)" Lines="@(_ReferencesLinkerFlags->'%(Identity)'->Substring (2))" Overwrite="true" />

    <ItemGroup>
      <!-- Backup collected required symbols -->
      <_ReferencesLinkerFlagsBackup Include="@(_ReferencesLinkerFlags)" />

      <!-- Clear `_ReferencesLinkerFlags` to prevent required symbols to be passed in -u_symbolName format -->
      <_ReferencesLinkerFlags Remove="@(_ReferencesLinkerFlags)" />
      <!-- Instruct platform linker to only export required symbols -->
      <_ReferencesLinkerFlags Include="-exported_symbols_list" />
      <_ReferencesLinkerFlags Include="$(_MtouchSymbolsList)" />
    </ItemGroup>
  </Target>

  <Target Name="_RestoreReferencesLinkerFlags" AfterTargets="_LinkNativeExecutable">
    <ItemGroup>
      <_ReferencesLinkerFlags Remove="@(_ReferencesLinkerFlags)" />
      <_ReferencesLinkerFlags Include="@(_ReferencesLinkerFlagsBackup)" />
    </ItemGroup>
  </Target>

Hope it helps.

MaxWroe commented 6 months ago

@MaxWroe

Regarding .NET8 - the next servicing release - should include the fix for .NET8

Regarding .NET7 - The workaround I posted above should work also in your scenario with some minimal changes. Forcing static linking mode is not needed as it is the default mode when building maccatalyst apps, so the workaround when targeting net7.0-maccatalyst would be:

<Target Name="_OverwriteReferencesLinkerFlags" BeforeTargets="_LinkNativeExecutable">
    <!-- Remove the `-u` prefix from `_ReferencesLinkerFlags` so we can give the output file to the platform linker -->
    <!-- NOTE: This step is actually also done after LinkNativeCode task, but we cannot intercept it differently -->
    <WriteLinesToFile SessionId="$(BuildSessionId)" File="$(_MtouchSymbolsList)" Lines="@(_ReferencesLinkerFlags->'%(Identity)'->Substring (2))" Overwrite="true" />

    <ItemGroup>
      <!-- Backup collected required symbols -->
      <_ReferencesLinkerFlagsBackup Include="@(_ReferencesLinkerFlags)" />

      <!-- Clear `_ReferencesLinkerFlags` to prevent required symbols to be passed in -u_symbolName format -->
      <_ReferencesLinkerFlags Remove="@(_ReferencesLinkerFlags)" />
      <!-- Instruct platform linker to only export required symbols -->
      <_ReferencesLinkerFlags Include="-exported_symbols_list" />
      <_ReferencesLinkerFlags Include="$(_MtouchSymbolsList)" />
    </ItemGroup>
  </Target>

  <Target Name="_RestoreReferencesLinkerFlags" AfterTargets="_LinkNativeExecutable">
    <ItemGroup>
      <_ReferencesLinkerFlags Remove="@(_ReferencesLinkerFlags)" />
      <_ReferencesLinkerFlags Include="@(_ReferencesLinkerFlagsBackup)" />
    </ItemGroup>
  </Target>

Hope it helps.

Can confirm that this appears to be working, thank you!

divil5000 commented 5 months ago

How do we know when this fix is live, and if we are developing using Visual Studio, what's the best way to get the fix?

It should go without saying, but since we are running in production, we cannot use preview software.

ivanpovazan commented 5 months ago

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 commented 5 months ago

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 commented 5 months ago

@divil5000 did you try the workaround posted by @ivanpovazan ? https://github.com/dotnet/runtime/issues/98941#issuecomment-2037327864

divil5000 commented 5 months ago

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 commented 5 months ago

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 https://github.com/dotnet/runtime/issues/98941#issuecomment-2006999639? 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 commented 5 months ago

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 commented 5 months ago

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 commented 5 months ago

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 commented 5 months ago

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 (https://github.com/dotnet/runtime/issues/98941#issuecomment-2006999639). 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 commented 5 months ago

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 commented 5 months ago

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 commented 5 months ago

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 https://github.com/dotnet/runtime/issues/98941#issuecomment-1978797262. Perhaps we should update the top-level workaround.

matouskozak commented 5 months ago

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 commented 4 months ago

@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 commented 4 months ago

@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 commented 4 months ago

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 commented 4 months ago

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 commented 4 months ago

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.