Sonar failing with Xcode 13

build-wrapper version 6.23 (macosx-x86)

Our CI machines have been updated to Xcode 13 and we’re getting the following error during analysis. I have a sonar-cfamily-reproducer.zip I can share privately to help look into the issue

13:47:49.118640 DEBUG [pool-3-thread-8] header.h:10 could not build module 'Foundation'
13:47:49.125518 DEBUG [pool-3-thread-8] /Applications/Xcode_13.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator15.0.sdk/System/Library/Frameworks/UIKit.framework/Headers/UIKit.h:8 could not build module 'Foundation'
java.lang.IllegalStateException: 
	at com.sonar.cpp.plugin.CFamilySensor.process(CFamilySensor.java:419)
	at com.sonar.cpp.plugin.CFamilySensor.execute(CFamilySensor.java:173)
	at org.sonar.scanner.sensor.AbstractSensorWrapper.analyse(AbstractSensorWrapper.java:48)
	at org.sonar.scanner.sensor.ModuleSensorsExecutor.execute(ModuleSensorsExecutor.java:85)
	at org.sonar.scanner.sensor.ModuleSensorsExecutor.execute(ModuleSensorsExecutor.java:62)
	at org.sonar.scanner.scan.ModuleScanContainer.doAfterStart(ModuleScanContainer.java:79)
	at org.sonar.core.platform.ComponentContainer.startComponents(ComponentContainer.java:137)
	at org.sonar.core.platform.ComponentContainer.execute(ComponentContainer.java:123)
	at org.sonar.scanner.scan.ProjectScanContainer.scan(ProjectScanContainer.java:382)
	at org.sonar.scanner.scan.ProjectScanContainer.scanRecursively(ProjectScanContainer.java:378)
	at org.sonar.scanner.scan.ProjectScanContainer.doAfterStart(ProjectScanContainer.java:347)
	at org.sonar.core.platform.ComponentContainer.startComponents(ComponentContainer.java:137)
	at org.sonar.core.platform.ComponentContainer.execute(ComponentContainer.java:123)
	at org.sonar.scanner.bootstrap.GlobalContainer.doAfterStart(GlobalContainer.java:136)
	at org.sonar.core.platform.ComponentContainer.startComponents(ComponentContainer.java:137)
	at org.sonar.core.platform.ComponentContainer.execute(ComponentContainer.java:123)
	at org.sonar.batch.bootstrapper.Batch.doExecute(Batch.java:72)
	at org.sonar.batch.bootstrapper.Batch.execute(Batch.java:66)
	at org.sonarsource.scanner.api.internal.batch.BatchIsolatedLauncher.execute(BatchIsolatedLauncher.java:46)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
	at java.base/java.lang.reflect.Method.invoke(Unknown Source)
	at org.sonarsource.scanner.api.internal.IsolatedLauncherProxy.invoke(IsolatedLauncherProxy.java:60)
	at com.sun.proxy.$Proxy0.execute(Unknown Source)
	at org.sonarsource.scanner.api.EmbeddedScanner.doExecute(EmbeddedScanner.java:185)
	at org.sonarsource.scanner.api.EmbeddedScanner.execute(EmbeddedScanner.java:137)
	at org.sonarsource.scanner.cli.Main.execute(Main.java:112)
	at org.sonarsource.scanner.cli.Main.execute(Main.java:75)
	at org.sonarsource.scanner.cli.Main.main(Main.java:61)

Hi @chrismash ,

what target are you building for?

That might have been useful to mention in my first message!

It should be iOS and it does seem to be iOS (I did wonder if it was trying to build it for macOS given UIKit is also being complained about).

Hi @chrismash ,

I don’t know whether it is the cause of your issue, we have a known issue with iOS analysis due to CPP-3276. It would be valuable if you could try to build and analyze for iOS simulator. If it will still fail I will then tell you what to do to help me with the investigation.

It’ll be analyzing for the simulator I imagine as we don’t have any physical devices connected to the CI machine (and you can see in the error log that it’s referencing the iphone simulator). It was working ok with Xcode 12, just since we’ve started running with Xcode 13 installed (as well as Xcode 12, so potentially having the two Xcode versions installed at the same time could cause some issues too).

As I say, I’ve got the sonar-cfamily-reproducer.zip that I can share with you if it’s likely to help? I’d rather share it privately though in case there’s anything sensitive in there!

Hi @chrismash ,

I sent you a private message.

Hi @chrismash ,

thank you for the reproducer, I managed to reproduce the issue: CPP-3285. It is going to be fixed in the next version of the analyzer.

1 Like

Thanks for the quick investigation Massimo! Is there any workaround you could suggest in the meantime (and/or an estimate for when the updated analyser will be available?)

Privately you suggested a workaround, which has avoided the issue but is reporting all manner of additional bugs and smells that weren’t reported previously (at least with Xcode 12), so isn’t much better unfortunately :smiley:

Hi @chrismash ,

yes, I know.

There is an alternative to try, which is to add the following macro definition to your build and by removing the previous workaround:

-DNS_FORMAT_ARGUMENT(A)

@mpaladin thanks for the suggestion of the workaround, I’m not sure where or how to apply it though, is it a compiler/build flag we set somewhere in Xcode? What effect does it have? I can only find one reference to it online (relating to Xcode 13 though!)

@mpaladin any advice on my previous question? And also any expected ETA for the next version of the analyser with the fix?

Hi @chrismash ,

another user applied the workaround this way:

The fix should come with the next version of the CFamily analyzer, which means it should make it into SonarQube 9.2, sometimes end of November. And hopefully mid-November on SonarCloud more or less.

1 Like