Compile error: strip exited with code 139

tipa commented 1 month ago

TLDR;

This is a regression reported in the Xarain repo in October 2023: https://github.com/xamarin/xamarin-macios/issues/19157
A temporary workaround might be to roll back to maui-ios workload 8.0.402 (see comment)
Rolf Kvinge has already found the problem and submitted a PR with a fix but it hasn't yet been merged. It would help for more people to report the problem to Apple, to try to get that prioritised.

Package

Sentry

.NET Flavor

.NET

.NET Version

8.0.8

OS

iOS

SDK Version

4.10.2

Self-Hosted Sentry Version

No response

Steps to Reproduce

Install Xcode 16 using Xcodes
Set Xcode 16 active (sudo xcode-select -s /Applications/Xcode-16.0.0.app/Contents/Developer)
Install .NET 8 tools with Xcode 16 support (see here)
Create new iOS app (dotnet new ios)
Add latest Sentry SDK (v4.10.2) from NuGet
dotnet publish

Expected Result

The app builds

Actual Result

Error while building: /usr/local/share/dotnet/packs/Microsoft.iOS.Sdk.net8.0_18.0/18.0.8287-xcode16/tools/msbuild/iOS/Xamarin.Shared.targets(2848,3): error : strip exited with code 139

This issue has been discussed previously here and a PR was created here (but not accepted yet).

For some reason, I was successful building my app successfully yesterday with the same tooling & Sentry version, but not today. It now consistently fails with every test project if I have the Sentry SDK added to, and it succeeds consistently when I remove it.

jamescrosswell commented 1 month ago

@tipa do you have your Sentry version pinned? A 4.11.0 release was made a few hours ago.

This is odd though as both the bug and the solution that you linked to seem to be part of a dotnet workload rather than part of Sentry.

tipa commented 1 month ago

The issue also happens for me with 4.11.0. I agree that this totally looks like a problem of dotnet or the Apple tooling - I opened this issue because you perhaps could or would want to workaround the issue since since the it can be reproduced so easily and reliably (at least in my dev environment now, with Xcode 16). Perhaps, as more users .NET users update to Xcode 16, more people could be affected. Are you able to reproduce the problem with the steps I provided?

bitsandfoxes commented 1 month ago

There are a couple of new issues regarding Cocoa and Xcode 16 as well so I don't expect this to be the last of our problems.

jamescrosswell commented 1 month ago

Are you able to reproduce the problem with the steps I provided?

I haven't had a chance to try this yet. I'm a bit nervous about installing XCode 16, at least until we can get all the groundwork in for Sentry working smoothly with net9.0... I'm trying to change as few things as possible, at once.

tipa commented 1 month ago

@jamescrosswell You can install XCode side-by-side with Xcode 15 - I explained the steps in my first post

jamescrosswell commented 1 month ago

You like living on the bleeding edge eh @tipa 😜 ?

Thanks for the tip re xcodes.

In this issue it looks like XCode 16 support will come with the net9.0 release in November.

I see in the NSTextList issue that there might be a preview coming in RC2 (~3 weeks away). Once RC2 is available, I'll see if I can reproduce. Even if we can't fix the problem, potentially we can research a workaround.

dotMorten commented 1 month ago

I'm also seeing this issue is back again with xcode16

jamescrosswell commented 1 month ago

I'm also seeing this issue is back again with xcode16

Until dotnet/maui supports XCode 16, I think the only practical workaround is to install Xcode 15.4 also/instead.

dotMorten commented 1 month ago

The latest MAUI workload requires XCode 16

jamescrosswell commented 1 month ago

The latest MAUI workload requires XCode 16

You mean if you target net9.0? We're working on net9.0 support. For MAUI, in particular, it's pretty challenging so it might take a while... hoping to have a pre-release available shortly after Microsoft release net9.0.

bitsandfoxes commented 1 month ago

We're forced to bump to Xcode 16 in CI now as well: https://github.com/getsentry/sentry-dotnet/pull/3635 Microsoft.iOS 18.0.8303 requires Xcode 16.0 or later. See this run

dotMorten commented 1 month ago

No even for net8

krobotics commented 1 month ago

I ran into this issue yesterday while trying to run a pipeline on devops (about the time that 18.0.8303 was released) got an error telling me to use xcode 16. This gave the code 139 error. Removing sentry from my code allowed the build on iOS. I can still build from Visual Studio but have not figure out how to get the pipeline to use xcode 15.4 and Microsoft.iOS.Sdk 17.5.8030.

jamescrosswell commented 1 month ago

We're forced to bump to Xcode 16 in CI now as well: https://github.com/getsentry/sentry-dotnet/pull/3635 Microsoft.iOS 18.0.8303 requires Xcode 16.0 or later. See this run

Aha - I see a new net8.0 release has been made to support XCode 16 👍🏻

UsherNet commented 1 month ago

Tried to update to latest CommunityToolkit.Maiu with requested updated workload then meant switching to Xcode 16, now facing the same "strip exited with code 139" error, which is preventing new builds from being produced for production. Now at a standstill until we can make sense of what is going on. I've tried different settings but continue to get the error. :(

angularsen commented 1 month ago

A workaround is to downgrade maui-ios workload by specifying the version:

dotnet workload install maui-ios --version 8.0.402

or if you build MAUI for both iOS and Android:

dotnet workload install maui --version 8.0.402

https://github.com/xamarin/xamarin-macios/issues/19157#issuecomment-2381265987

bitsandfoxes commented 1 month ago

Thanks @angularsen for providing a workaround!

We're working on resolving this as soon as possible.

bitsandfoxes commented 1 month ago

Good news is: I cannot reproduce this anymore with the steps provided in the issue description in my local environment. Bad news is: I don't know what changed. Because there are no changes to the SDK that I'm aware of that could have fixed the issue. Is this just all in the dependencies?

dotMorten commented 1 month ago

I'm finding the issue occurs randomly. I can often build it at few times and sometimes it fails and others it works.

jamescrosswell commented 1 month ago

Can someone who is able to reproduce this problem try with version 4.12.0 of the Sentry SDK? That version of the SDK has been compiled and linked using XCode 16...

AndreyPhilippov commented 1 month ago

Can someone who is able to reproduce this problem try with version 4.12.0 of the Sentry SDK? That version of the SDK has been compiled and linked using XCode 16...

@jamescrosswell I can confirm from my side that v4.12.0 doesn't work. I use two packages

<PackageReference Include="Sentry" Version="4.12.0" />
<PackageReference Include="Sentry.Serilog" Version="4.12.0" />

Removing references to sentry fix the issue for me.

bruno-garcia commented 1 month ago

Can someone who is able to reproduce this problem try with version 4.12.0 of the Sentry SDK? That version of the SDK has been compiled and linked using XCode 16...

@jamescrosswell I can confirm from my side that v4.12.0 doesn't work. I use two packages
<PackageReference Include="Sentry" Version="4.12.0" />
<PackageReference Include="Sentry.Serilog" Version="4.12.0" />
Removing references to sentry fix the issue for me.

To confirm: Are you on Xcode 16 and you updated your dotnet workloads? Please confirm since that seems to work for us. For folks on Xcode 15.4 or earlier, Sentry's SDK 4.11 or lower are required.

We're adding this to the changelog:

If you are using Xcode 16.0, you will need to update the SDK to version 4.12.0 or later. If you are still using Xcode 15.4 or earlier, you need to continue to use version 4.11.0 or earlier.

Using Xcode 16 to build .NET applications targeting iOS and Mac Catalyst requires .NET workload for iOS SDK version 18.0.8303. We built the SDK version 4.12.0 using Xcode 16 in order to support this scenario. That, unfortunately, breaks folks using older version of Xcode.

As such, if you are using SDK version 4.12.x and targeting iOS or Mac Catalyst, you will need to install and use Xcode 16 and workload iOS SDK 18.0.8303

Note that .NET 9 will also support Xcode 16, when it is released next month (Nov 2024).

AndreyPhilippov commented 1 month ago

@bruno-garcia Yes, I use Xcode 16.0 and workload iOS SDK 18.0.8303.

angularsen commented 1 month ago

It started working the recent couple of days on Azure Pipelines when running

dotnet workload install maui # No longer need to specify --version 8.0.402.1
sudo xcode-select -s /Applications/Xcode_16.app

This installs microsoft.net.sdk.ios version 18.0.8303 and we no longer get strip exit code 139 🎉

If you are running on Azure Pipelines, I assume the VM images were recently upgraded, and maybe it takes time to roll out to all regions.

tipa commented 1 month ago

The problem still persists for me too, with Microsoft.iOS.Sdk.net8.0_18.0/18.0.8303 & Sentry 4.12.0

angularsen commented 1 month ago

So, it seems flaky for us when not specifying workload version and it depends on the build agent VM image version in Azure Pipelines. Interestingly, the newer VM image fails, but the 7 day older VM image works.

Working version (Sep 23): macos-14 20240923.101

Image: macos-14 Version: 20240923.101 Included Software: https://github.com/actions/runner-images/blob/macos-14/20240923.101/images/macos/macos-14-Readme.md Image Release: https://github.com/actions/runner-images/releases/tag/macos-14%2F20240923.101

Non-working version (Sep 30): macos-14 20240930.130

Image: macos-14 Version: 20240930.130 Included Software: https://github.com/actions/runner-images/blob/macos-14/20240930.130/images/macos/macos-14-Readme.md Image Release: https://github.com/actions/runner-images/releases/tag/macos-14%2F20240930.130

The only relevant difference I can spot is that .NET Core SDK was bumped from 8.0.401 to 8.0.402.

Update: New version (Oct 7): macos-14 20241007.165 released, not yet sure if it helps

Yesterday a new VM image was released and just popped up in our builds, but I don't see any relevant changes that may improve the situation and it seems you can't request builds with a specific VM image version so I can't easily test if it fixes the problem.

Image: macos-14 Version: 20241007.165 Included Software: https://github.com/actions/runner-images/blob/macos-14/20241007.165/images/macos/macos-14-Readme.md Image Release: https://github.com/actions/runner-images/releases/tag/macos-14%2F20241007.165

AndreyPhilippov commented 1 month ago

So, it seems flaky for us when not specifying workload version and it depends the build agent VM image version in Azure Pipelines. Interestingly, the newer VM image fails, but the 7 day older VM image works.

Working version (Sep 23): macos-14 20240923.101

Image: macos-14 Version: 20240923.101 Included Software: https://github.com/actions/runner-images/blob/macos-14/20240923.101/images/macos/macos-14-Readme.md Image Release: https://github.com/actions/runner-images/releases/tag/macos-14%2F20240923.101

Non-working version (Sep 30): macos-14 20240930.130

Image: macos-14 Version: 20240930.130 Included Software: https://github.com/actions/runner-images/blob/macos-14/20240930.130/images/macos/macos-14-Readme.md Image Release: https://github.com/actions/runner-images/releases/tag/macos-14%2F20240930.130

The only relevant difference I can spot is that .NET Core SDK was bumped from 8.0.401 to 8.0.402.

I also noticed this. My Azure pipeline was fine with macos-14 / Xcode 16 / iOS SDK 18.0.8303 / Sentry 4.9.0 setup. And just recently starting from 1 October it has started to fail. On my local machine it fails as well.

angularsen commented 1 month ago

I managed to randomly queue a build with the brand new VM image version (Oct 7): macos-14 20241007.165

Not sure if this is simply a flaky problem or not, but the newest version built successfully with default worload version:

dotnet workload install maui # No longer need to specify --version 8.0.402.1
sudo xcode-select -s /Applications/Xcode_16.app

Azure Pipelines VM versions:

macos-14 20240923.101: OK
macos-14 20240930.130: strip error code 139
macos-14 20241007.165: OK

AndreyPhilippov commented 1 month ago

@angularsen How do you able to use exactly 20241007.165 vmImage version? Did you specifically selected it on azure portal or your yml file?

angularsen commented 1 month ago

@AndreyPhilippov No it seems not possible to configure, so I just requeued the build until I got the version I wanted.

AndreyPhilippov commented 1 month ago

I can confirm that on Azure macos-14 20241007.165 image my project builts successfully. But still on my local machine with macOS 15 it fails.

jamescrosswell commented 1 month ago

But still on my local machine with macOS 15 it fails.

I'm still on 14.6.1 locally and I see our CI builds on GitHub are running macOS 13.7.

This appears to be the target that is performing the failing strip operation: https://github.com/xamarin/xamarin-macios/blob/fb9675bdbd34499bb8580ea8708990282f8cee01/msbuild/Xamarin.Shared/Xamarin.Shared.targets#L2848-L2855

Under the hood that seems to be running xcrun on the host operating system: https://github.com/xamarin/xamarin-macios/blob/fb9675bdbd34499bb8580ea8708990282f8cee01/msbuild/Xamarin.MacDev.Tasks/Tasks/SymbolStrip.cs#L55

From what I can tell, xcrun is a util that helps run the correct version of Xcode tools when you have multiple versions installed.

It doesn't sound like the OS is directly relevant then - but it may indirectly determine the default/active version of Xcode, if you're not setting this explicitly in your build scripts.

The Sentry build scripts explicitly set Xcode 16 as the tooling to use: https://github.com/getsentry/sentry-dotnet/blob/9accd2f826755a2258fc13c2d8f4e9419ddbc26e/.github/workflows/build.yml#L12-L13 https://github.com/getsentry/sentry-dotnet/blob/9accd2f826755a2258fc13c2d8f4e9419ddbc26e/.github/workflows/build.yml#L73-L77

evgenyvalavin commented 1 month ago

What if to use this:

<PropertyGroup>
    <_ExportSymbolsExplicitly>false</_ExportSymbolsExplicitly>
</PropertyGroup>

For me it fixes the error

jamescrosswell commented 1 month ago

<PropertyGroup>
  <_ExportSymbolsExplicitly>false</_ExportSymbolsExplicitly>
</PropertyGroup>

For me it fixes the error

Can anyone else who's experiencing this error confirm this? If so, it may be related to https://github.com/xamarin/xamarin-macios/pull/18408 and we could ask one of the maintainers there if they might know why we're running into this.

UsherNet commented 1 month ago

I’m getting the same error when NOT using Sentry, but including the Community Toolkit. So it is NOT just relating to Sentry.

jamescrosswell commented 1 month ago

I’m getting the same error when NOT using Sentry, but including the Community Toolkit. So it is NOT just relating to Sentry.

Hm, @dotMorten / @rolfbjarne could it possibly be this again?

https://github.com/xamarin/xamarin-macios/issues/19157

Maybe once a year in October it comes back to haunt us 👻

@rolfbjarne it looks like the PR you made to address this never got merged, so that might explain why.

jamescrosswell commented 1 month ago

So an interim summary, I think:

This is a regression reported in the Xamarin repo in October 2023: https://github.com/xamarin/xamarin-macios/issues/19157
A temporary workaround might be to roll back to maui-ios workload 8.0.402 (see comment)
Rolf Kvinge has already found the problem and submitted a PR with a fix but it hasn't yet been merged. It would help for more people to report the problem to Apple, to try to get that prioritised.
- https://github.com/apple-oss-distributions/cctools/pull/2

One thing I'm not sure of yet is whether we need to rebuild the Sentry SDK, pinning the maui-ios workload to version 8.0.402... or whether it's sufficient for app developers to do that when building their apps. I suspect we might have to rollback in the SDK too.

softlion commented 1 month ago

With 8.0.403 it is compiling ok.

AndreyPhilippov commented 1 month ago

<PropertyGroup>
    <_ExportSymbolsExplicitly>false</_ExportSymbolsExplicitly>
</PropertyGroup>
For me it fixes the error
Can anyone else who's experiencing this error confirm this? If so, it may be related to xamarin/xamarin-macios#18408 and we could ask one of the maintainers there if they might know why we're running into this.

This helped me too.

tipa commented 1 month ago

@jamescrosswell this issue is tagged "Needs reproduction". Are you not able to reproduce it?

The workaround of specifying _ExportSymbolsExplicitly=false increases my app size significantly: Without Sentry and without _ExportSymbolsExplicitly=false, my app's install size is reported by TestFlight with 23.6 MB. With Sentry and with _ExportSymbolsExplicitly=false, it is reported as 43.5 MB. This is a huge difference! At the moment I cannot test how large the "normal" (without skipping "strip") size impact of the Sentry SDK would be. However, before upgrading to .NET9/Xcode16, my app's install size was around 33 MB (and I've seen that .NET9 further reduced my app size on an app that is not using Sentry).

The workaround you edited into my first post above doesn't apply to me as I am not using maui, but "plain" net-ios. Additionally I don't want to downgrade my workload to .NET8, since I am already using .NET9

jamescrosswell commented 1 month ago

Hi @tipa

The workaround you edited into my first post above doesn't apply to me as I am not using maui, but "plain" net-ios. Additionally I don't want to downgrade my workload to .NET8, since I am already using .NET9

That complicates things. We're working on net9.0 support for version 5.0.0 of the .NET SDK for Sentry. Version 4.x won't work with net9.0... so even if you revert to the old linking behaviour with _ExportSymbolsExplicitly=false, you're still not going to be able to target net9.0 and use Sentry in your application.

In your case then, you've only got a few options:

revert to the old linking behaviour by setting _ExportSymbolsExplicitly=false
roll back to maui-ios workload 8.0.402
wait until Sentry 5.0 is released with .net9 support

tipa commented 1 month ago

@jamescrosswell thanks for your response. Hope the v5 is ready soon then. In my tests I still get crash reports - both automatically reported ones as well as those I send manually. What exactly isn't working with v4.x & .NET 9?

jamescrosswell commented 1 month ago

What exactly isn't working with v4.x & .NET 9?

On the face of it, it seems trivial. Our build scripts include some naive conditions like Condition="$(TargetFramework.StartsWith('net8'))"> that need to be updated to <PropertyGroup Condition="($(TargetFramework.StartsWith('net8')) Or $(TargetFramework.StartsWith('net9')))"> instead. Certain features like Native AOT compilation won't work on net9.0 without those changes to the build scripts. That would affect you directly as an SDK user.

The real challenge with net9.0 is support for android and ios, however. the net9.0 tooling drops support for net7.0, so we have to bump to at least net8.0-ios and net8.0-android and that breaks our device tests... which would certainly impact you indirectly, if we can't find a resolution.

tipa commented 1 month ago

Certain features like Native AOT compilation won't work on net9.0

I'm surprised to hear that because I am able to compile my app using Sentry 4.12.1 and PublishAot=true...

Also, with the help of this workaround I was able to compile a fixed version of strip and then compile my app without setting _ExportSymbolsExplicitly=false. I'll see how it goes... Now I can also see the size impact of the Sentry SDK - it increases my .ipa bundle size from 12.8 MB to 16.6 MB - a 30% increase. Or is that what you mentioned by not being net9.0 compatible - that the Sentry SDK alone is not Native AOT compiled and therefore larger in size? Edit: I just noticed that the install size increased dramatically from 34MB with .NET 8 to 74 MB with .NET 9 - so it looks like the app is compiled successfully - just not with Native AOT... looking forward to the Sentry v5

MichaelAzzer commented 3 weeks ago

iOS Symbol Stripping Issue With Sentry Solution for .NET MAUI and .NET9_RC2 Problem When building a .NET MAUI iOS app in Release mode, you might encounter symbol stripping errors, especially when using packages like Sentry or other packages that require symbol preservation. Solution Step 1: Create LinkDescription.xml Create a new file called LinkDescription.xml in your MAUI project root and add this content:

<linker>
    <!-- Add assemblies that need symbol preservation -->
    <assembly fullname="Sentry.Maui">
        <type fullname="Sentry.Maui.*" preserve="all"/>
    </assembly>
    <!-- Add other assemblies as needed -->
</linker>

Step 2: Include LinkDescription in Project Add this to your .csproj to include the LinkDescription file:

<ItemGroup>
    <LinkDescription Include="LinkDescription.xml" />
</ItemGroup>

Step 3: Configure Build Properties Add these properties to your .csproj:

<PropertyGroup Condition="'$(Configuration)|$(TargetFramework)|$(Platform)'=='Release|net9.0-ios|AnyCPU'">
    <!-- Use linker description -->
    <MtouchExtraArgs>--xml=$(MSBuildProjectDirectory)/LinkDescription.xml</MtouchExtraArgs>
</PropertyGroup>

What This Does

MtouchNoSymbolStrip>false: Enables symbol stripping to reduce app size LinkDescription.xml: Tells the linker which assemblies need their symbols preserved MtouchExtraArgs: Points to your LinkDescription file

Notes

This solution allows for symbol stripping while preserving necessary symbols for specific assemblies Results in smaller app size compared to disabling symbol stripping entirely Modular approach - easy to add more assemblies as needed

Let me know if this works for you

bruno-garcia commented 3 weeks ago

Thanks for sharing that @MichaelAzzer

Hope folks share how that worked for them.

jamescrosswell commented 5 days ago

Given this issue doesn't appear to originate from the Sentry repository and there are various workarounds described by folks above, I'll close this. Please reopen if you think there's anything more we should be doing in the Sentry repository.

christostatitzikidis commented 3 days ago

The above solution intermittently works for me. The same as a simplified version of it using TrimmerRootAssembly as mentioned at https://learn.microsoft.com/en-us/dotnet/maui/ios/linking?view=net-maui-8.0&viewFallbackFrom=net-maui-9.0#preserve-assemblies-types-and-members. But it's not reliable as it can succeed and the next time it will fail.

Removing Sentry altogether results in consistently successful builds. We are also using latest CommunityToolkit, with no issues whatsoever.

jamescrosswell commented 2 days ago

@christostatitzikidis did you try this workaround? It would be very unusual to get an error related to stripping symbols from Sentry if you're not stripping symbols from the Sentry package.

MichaelAzzer commented 2 days ago

I want to mention that the problem not in Sentry But the problem with xcode 16 itself and we still need fix from Apple

getsentry / sentry-dotnet