sentry-dotnet icon indicating copy to clipboard operation
sentry-dotnet copied to clipboard

Compile error: strip exited with code 139

Open tipa opened this issue 1 year ago • 44 comments

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

  1. Install Xcode 16 using Xcodes
  2. Set Xcode 16 active (sudo xcode-select -s /Applications/Xcode-16.0.0.app/Contents/Developer)
  3. Install .NET 8 tools with Xcode 16 support (see here)
  4. Create new iOS app (dotnet new ios)
  5. Add latest Sentry SDK (v4.10.2) from NuGet
  6. 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.

tipa avatar Sep 20 '24 11:09 tipa

@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.

jamescrosswell avatar Sep 23 '24 01:09 jamescrosswell

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?

tipa avatar Sep 23 '24 06:09 tipa

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.

bitsandfoxes avatar Sep 23 '24 20:09 bitsandfoxes

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.

jamescrosswell avatar Sep 23 '24 22:09 jamescrosswell

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

tipa avatar Sep 23 '24 22:09 tipa

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.

jamescrosswell avatar Sep 24 '24 06:09 jamescrosswell

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

dotMorten avatar Sep 26 '24 23:09 dotMorten

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.

jamescrosswell avatar Sep 26 '24 23:09 jamescrosswell

The latest MAUI workload requires XCode 16

dotMorten avatar Sep 26 '24 23:09 dotMorten

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.

jamescrosswell avatar Sep 27 '24 06:09 jamescrosswell

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

bitsandfoxes avatar Sep 27 '24 10:09 bitsandfoxes

No even for net8

dotMorten avatar Sep 27 '24 13:09 dotMorten

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.

krobotics avatar Sep 27 '24 14:09 krobotics

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 👍🏻

jamescrosswell avatar Sep 27 '24 20:09 jamescrosswell

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. :(

UsherNet avatar Sep 30 '24 04:09 UsherNet

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

angularsen avatar Sep 30 '24 06:09 angularsen

Thanks @angularsen for providing a workaround!

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

bitsandfoxes avatar Sep 30 '24 16:09 bitsandfoxes

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?

bitsandfoxes avatar Oct 01 '24 15:10 bitsandfoxes

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

dotMorten avatar Oct 01 '24 15:10 dotMorten

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 avatar Oct 02 '24 22:10 jamescrosswell

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.

AndreyPhilippov avatar Oct 07 '24 13:10 AndreyPhilippov

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).

bruno-garcia avatar Oct 08 '24 02:10 bruno-garcia

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

AndreyPhilippov avatar Oct 08 '24 07:10 AndreyPhilippov

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.

angularsen avatar Oct 08 '24 07:10 angularsen

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

tipa avatar Oct 08 '24 08:10 tipa

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

angularsen avatar Oct 08 '24 08:10 angularsen

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.

AndreyPhilippov avatar Oct 08 '24 08:10 AndreyPhilippov

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

angularsen avatar Oct 08 '24 10:10 angularsen

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

AndreyPhilippov avatar Oct 08 '24 10:10 AndreyPhilippov

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

angularsen avatar Oct 08 '24 10:10 angularsen