ICU causes crash on iOS 17.4 simulator #98941
Comments
ghost
added
the
dotnet-issue-labeler
bot
added
the
needs-area-label
|
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) |
vcsjones
added
area-System.Globalization
os-ios
|
Tagging subscribers to this area: @dotnet/area-system-globalization Issue DetailsDescriptionApp 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
var date = NSDate.Now;
var locale = NSLocale.SystemLocale;
var str = date.DescriptionWithLocale (locale);
Note: an iOS 17.2 simulator works just fine. Expected behaviorNo crash. Actual behaviorCrash: Full crash report: https://gist.github.com/rolfbjarne/9fcedeb59d0521c4c9bb931056bba15c Regression?Yes. Fortunately it seems to only affect the simulator, and not device. Known WorkaroundsDisable 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 foundOther informationNo response
|
|
CC @akoeplinger |
|
@rolfbjarne @tarekgh @vitek-karas this is net8 so it isn't using hybrid globalization |
Weird, I'm mentioned, but got no notification of this. @rolfbjarne confirming this is off of a .net 8 runtime? |
|
@lewing I didn't claim it is from hybird globalization 😄 looking at the stack 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. 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 but from stacktrace these functions are not called. |
Confirmed, this is with stable versions of everything (except Xcode). |
|
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, |
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? |
|
Xcode 15.3 RC 1 is out and unfortunately we can still repro the issue |
That might be it. Looking at the difference between versions: shows: On the other hand, our latest |
|
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 One workaround that I think might be acceptable risk-wise is to rename the exported symbols to have e.g. a |
We did this numerous times in Mono. |
|
@steveisok .NET 9 seems to be working fine |
|
@steveisok / @vitek-karas any news on this issue? |
@dalexsoto looks like we're going to try this approach. Unsure of an ETA at this time. |
|
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 |
|
The fix unfortunately did not reach |
|
Is there a recommended workaround if we are using net8-iOS? It's when running on Mac that our users are hitting crashes. |
|
@divil5000 did you try the workaround posted by @ivanpovazan ? #98941 (comment) |
|
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. |
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.
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. |
|
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.
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.
Do you have a crash report? |
|
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. |
|
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 |
You are right, forcing |
|
The .NET 8.0.5 servicing is out and the fix is in. I verified locally that the sample app with no longer crashes on iOS 17.4 simulator. @rolfbjarne could you verify from Xamarin side that everything works as expected? |
|
@matouskozak @rolfbjarne Has 8.0.5 been published on NuGet to be available via 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? |
|
Thanks @matouskozak. I can confirm I have .NET 8.0.300 SDK installed: 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 OS is macOS Sonoma 14.5 with Xcode 15.4. |
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. |
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 |
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
dotnet new iosNote: an iOS 17.2 simulator works just fine.
Expected behavior
No crash.
Actual behavior
Crash:
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:
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 foundOther information
No response
The text was updated successfully, but these errors were encountered: