Bug 42392 - 'clang: error: unable to execute command: Segmentation fault: 11' when compiling ios project
Summary: 'clang: error: unable to execute command: Segmentation fault: 11' when compil...
Alias: None
Product: iOS
Classification: Xamarin
Component: General (show other bugs)
Version: XI 9.8 (tvOS / C7)
Hardware: Macintosh Mac OS
: High critical
Target Milestone: 10.0.0 (C8)
Assignee: Bugzilla
Depends on:
Reported: 2016-07-07 02:02 UTC by ben ishiyama-levy
Modified: 2016-08-26 13:54 UTC (History)
9 users (show)

Tags: C8Beta1
Is this bug a regression?: Yes
Last known good build: 9.6.2

Cycle6 Débug|iPhone Log (954.73 KB, text/plain)
2016-07-14 04:27 UTC, ben ishiyama-levy
Reproduction of the linking error with PostSharp (121.07 KB, application/x-zip-compressed)
2016-07-18 13:58 UTC, alex

Notice (2018-05-24): bugzilla.xamarin.com is now in read-only mode.

Please join us on Visual Studio Developer Community and in the Xamarin and Mono organizations on GitHub to continue tracking issues. Bugzilla will remain available for reference in read-only mode. We will continue to work on open Bugzilla bugs, copy them to the new locations as needed for follow-up, and add the new items under Related Links.

Our sincere thanks to everyone who has contributed on this bug tracker over the years. Thanks also for your understanding as we make these adjustments and improvements for the future.

Please create a new report on Developer Community or GitHub with your current version information, steps to reproduce, and relevant error messages or log files if you are hitting an issue that looks similar to this resolved bug and you do not yet see a matching new report.

Related Links:

Description ben ishiyama-levy 2016-07-07 02:02:55 UTC
# Steps to reproduce
Within visual studio (or using msbuild cli)
Compile the xamarin ios project of xamarin form solution with any iPhone configuration (simulator is ok).
linker in all configurations (skipping most of my project assemblies when linkall)

# Expected behavior
The project compiles

# Actual behavior
compilation error with the following:
11> clang: error: unable to execute command: Segmentation fault: 11
11> clang: error: linker command failed due to signal (use -v to see invocation)
11>C:\Program Files (x86)\MSBuild\Xamarin\iOS\Xamarin.iOS.Common.targets(673,3): error : Native linking error: clang: error: unable to execute command: Segmentation fault: 11
11>C:\Program Files (x86)\MSBuild\Xamarin\iOS\Xamarin.iOS.Common.targets(673,3): error : Native linking error: clang: error: linker command failed due to signal (use -v to see invocation)
11>C:\Program Files (x86)\MSBuild\Xamarin\iOS\Xamarin.iOS.Common.targets(673,3): error : Native linking failed. Please review the build log.

# Supplemental info (logs, images, videos)

# Test environment (full version information)
Latest Cycle 7 at the time of writing:
Xamarin.iOS OSX 9.8.1
Xamarin.iOS Windows 4.1.1
Windows 10
Visual Studio 14.0.25123.00 Update 2

Comment 1 ben ishiyama-levy 2016-07-07 02:03:45 UTC
a while back, we came across the compile time issue 'clang: error: unable to execute command: Segmentation fault: 11' that made debugging on ios device impossible: https://bugzilla.xamarin.com/show_bug.cgi?id=25303
It was all fine, until we tried Cycle7 a few weeks ago, but now the compile error is not limited to Debug configuration, but also to release.
Comment 2 Samantha Houts [MSFT] 2016-07-07 18:42:55 UTC
I see that you are using third-party libraries that reference Xamarin.Forms. Have you updated all of those libraries when you updated Xamarin.Forms to 2.3.1-pre? Do you still get this error if you do not reference those libraries? 

Please see if you are able to reproduce this error with a clean Xamarin.Forms project.

Warm regards, 
Xamarin Forms Team
Comment 3 ben ishiyama-levy 2016-07-10 01:41:49 UTC

Yes, I updated all those libraries.
It appears that the Library Postsharp is the culprit, although it always allowed me to Deploy an iphone ipa until cycle 7. Cycle 6 on ipPhone Debug causes the same issue;
Staring from a fresh project does not causes any problems, but our project does, and that is a pretty massive project.
In any case, something changed from cycle 6 to cycle 7 that causes the inability to deploy ipa with our current setup, with postsharp enabled.

So i am looking into it with postsharp, but any info or help your end would be immensely appreciated.
Comment 4 Samantha Houts [MSFT] 2016-07-11 17:41:24 UTC
The deployment location of the .ipa package changed in Cycle 7 for Xamarin.iOS. You can find details about that here: https://developer.xamarin.com/releases/ios/xamarin.ios_9/xamarin.ios_9.8/#Bug_Fixes
Comment 5 Samantha Houts [MSFT] 2016-07-11 17:47:08 UTC
Marking as resolved answered for now, but please let us know if we can be of further assistance. Thank you!
Comment 6 ben ishiyama-levy 2016-07-12 10:35:48 UTC

@Samantha, Please reopen,that has nothing much to do with the location of ipa;
There is a regression from cycle 6+ to cycle 7, as deploying works on 6 and not on 7;
A library we are using, PostSharp, is a part of where it breaks, but it does break due to a regression on the xamarin sdk;
This is causing a pretty big blocker as we are no longer able to debug on devices no matter what, and are unable to update to cycle 7 as our app won't deploy to device.
Comment 7 Rolf Bjarne Kvinge [MSFT] 2016-07-12 16:44:13 UTC
It looks like the native linker (from Apple's toolchain) is crashing.

Can you try and see if it works if you compile the project using Xamarin Studio on a Mac (my guess is that it will still fail though)?

If that doesn't work, please attach the complete build log.
Comment 8 ben ishiyama-levy 2016-07-13 00:07:12 UTC

As postsharp is a Windows code weaving process fired by a msbuild task, it only triggers on windows, so yes, compilation works on MAC, but acts as having the postsharp task disabled. As a result, the postsharp aspects (code attached to methods via marker attributes that will tell the postsharp process to weave the related code there, in the same way mono.cecil works) are not processed.
As per my previous comment, cycle 6 release mode works fine, cycle 7 breaks, with the same postsharp version, and sane Xcode version. So something on the xamarin sdk in cycle 7 broke.
Comment 9 Rolf Bjarne Kvinge [MSFT] 2016-07-13 20:45:17 UTC
@Ben, can you add "-v -v -v -v" to the additional mtouch arguments in the project's iOS Build, clean & rebuild and then attach the complete build log here?
Comment 10 ben ishiyama-levy 2016-07-14 03:41:11 UTC
Hi Rolf,

Postsharp engineers could reproduce the regression and should be in touch with the Xamarin team to share their findings; Or get in touch with them.
See thread there:
Comment 11 ben ishiyama-levy 2016-07-14 03:49:26 UTC
attaching the log with "-v -v -v -v" as indicated,
that's Cycle 6 latest version, in Debug|iPhone config (samoe outcome, but release is all ok)
Comment 12 ben ishiyama-levy 2016-07-14 04:27:39 UTC
Created attachment 16661 [details]
Cycle6 Débug|iPhone Log

log with "-v -v -v -v" as indicated,
that's Cycle 6 latest version, in Debug|iPhone config (same outcome, but release is all ok)
Comment 13 Rolf Bjarne Kvinge [MSFT] 2016-07-14 14:35:44 UTC
OK, I'll wait for feedback from the Postsharp engineers then.
Comment 14 alex 2016-07-18 13:58:33 UTC
Created attachment 16704 [details]
Reproduction of the linking error with PostSharp

You can find the reproduction in the attached LinkingErrorRepro.zip archive.

To reproduce the issue open TestSolution\LinkingErrorRepro.sln in VisualStudio and build TestApp.csproj for iPhone configuration. There's *.mdb file in the lib folder and it seems that removing this file solves the issue.

Unfortunately, we are not able yet to provide you with the source code for the corresponding project that outputs that *.mdb file and library itself. It's tied to our complete testing framework and isolating the code into a smaller project didn't reproduce the issue yet.

Please let us know if there's anything else we can provide to help you with debugging.
Comment 15 Rolf Bjarne Kvinge [MSFT] 2016-07-18 14:26:59 UTC
Info provided: reopening.
Comment 16 Vincent Dondain [MSFT] 2016-07-25 10:33:06 UTC
Re-uploading the test case as the csproj was incorrect (mix between Xamarin.iOS Classic and Unified): https://www.dropbox.com/s/lpy03581098r5ru/LinkingErrorRepro.zip?dl=0

I am also able to reproduce the issue, getting build errors when building for debug/device, see: https://gist.github.com/VincentDondain/d415f26756ad50099984af17830c0917

Removing the *.mdb file in the lib folder fixes the build, so it *does* seem to be the root of the issue.

I'm marking the bug as confirmed.

Indeed with C6 builds I'm not getting the same linker error. However I'm getting "MTOUCH: error MT2002: Failed to resolve "System.String System.String::Format(System.IFormatProvider,System.String,System.Object,System.Object)" reference from "mscorlib, Version=, Culture=neutral, PublicKeyToken=7cec85d7bea7798e"" (likely related to something else)


The error being different, I'm considering the linker issue a regression from cycle6.
Comment 17 GouriKumari 2016-08-12 20:07:57 UTC
>>The error being different, I'm considering the linker issue a regression from cycle6.

Changing the status to High|Critical.
Comment 18 Sebastien Pouliot 2016-08-26 13:54:46 UTC
I am not able to duplicate the issue using the latest C8 builds.

> Removing the *.mdb file in the lib folder fixes the build

There was an issue where XVS could produce incorrect .mdb (fixed in C7SR2) that might have been the original problem.

QA: please validate from both the Mac/XS and Windows/VS, thanks!