SonarCloud analysis failing with CFamily plugin version: 6.53.0.67215

SonarCloud
,
1

Sonar Cloud connected to Bitrise within SonarQube Scanner step
INFO: SonarScanner 4.6.2.2472
INFO: Java 17.0.9
INFO: Mac OS X 14.1.2
INFO: Xcode 15.3

When I used CFamily plugin version: 6.52.1.66618 it worked as expected

Running the analysis from the pipeline stops with several of these errors

INFO: Sensor Generic Coverage Report (done) | time=260ms
INFO: Sensor CFamily [cpp]
INFO: CFamily plugin version: 6.53.0.67215
INFO: Using compile commands: /Users/vagrant/git/compile_commands.json
INFO: Available processors: 4
INFO: Using 4 threads for analysis.
INFO: Found empty cache on server
INFO: ------------------------------------------------------------------------
INFO: EXECUTION FAILURE
INFO: ------------------------------------------------------------------------
INFO: Total time: 32.983s
INFO: Final Memory: 72M/250M

INFO: ------------------------------------------------------------------------

ERROR: Error during SonarScanner execution
java.lang.IllegalStateException: unexpanded response file
at com.sonar.cpp.analyzer.ClangDriver.onCapture(ClangDriver.java:540)
at com.sonar.cpp.analyzer.CompilerDrivers.onCapture(CompilerDrivers.java:36)
at com.sonar.cpp.plugin.CFamilySensor.lambda$process$37(CFamilySensor.java:1447)
at com.sonar.cpp.plugin.CompileCommandsReader.readCaptures(CompileCommandsReader.java:61)
at com.sonar.cpp.plugin.CFamilySensor.process(CFamilySensor.java:1445)
at com.sonar.cpp.plugin.CFamilySensor.processConfigurationReader(CFamilySensor.java:750)
at com.sonar.cpp.plugin.CFamilySensor.lambda$process$4(CFamilySensor.java:468)
at java.base/java.lang.Iterable.forEach(Iterable.java:75)
at com.sonar.cpp.plugin.CFamilySensor.process(CFamilySensor.java:468)
at com.sonar.cpp.plugin.CFamilySensor.execute(CFamilySensor.java:241)
at org.sonar.scanner.sensor.AbstractSensorWrapper.analyse(AbstractSensorWrapper.java:62)
at org.sonar.scanner.sensor.ModuleSensorsExecutor.execute(ModuleSensorsExecutor.java:75)
at org.sonar.scanner.sensor.ModuleSensorsExecutor.execute(ModuleSensorsExecutor.java:51)
at org.sonar.scanner.scan.ModuleScanContainer.doAfterStart(ModuleScanContainer.java:64)
at org.sonar.core.platform.ComponentContainer.startComponents(ComponentContainer.java:123)
at org.sonar.core.platform.ComponentContainer.execute(ComponentContainer.java:109)
at org.sonar.scanner.scan.ProjectScanContainer.scan(ProjectScanContainer.java:192)
at org.sonar.scanner.scan.ProjectScanContainer.scanRecursively(ProjectScanContainer.java:188)
at org.sonar.scanner.scan.ProjectScanContainer.doAfterStart(ProjectScanContainer.java:159)
at org.sonar.core.platform.ComponentContainer.startComponents(ComponentContainer.java:123)
at org.sonar.core.platform.ComponentContainer.execute(ComponentContainer.java:109)
at org.sonar.scanner.bootstrap.ScannerContainer.doAfterStart(ScannerContainer.java:397)
at org.sonar.core.platform.ComponentContainer.startComponents(ComponentContainer.java:123)
at org.sonar.core.platform.ComponentContainer.execute(ComponentContainer.java:109)
at org.sonar.scanner.bootstrap.GlobalContainer.doAfterStart(GlobalContainer.java:125)
at org.sonar.core.platform.ComponentContainer.startComponents(ComponentContainer.java:123)
at org.sonar.core.platform.ComponentContainer.execute(ComponentContainer.java:109)
at org.sonar.batch.bootstrapper.Batch.doExecute(Batch.java:57)
at org.sonar.batch.bootstrapper.Batch.execute(Batch.java:51)
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(NativeMethodAccessorImpl.java:77)
at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:568)
at org.sonarsource.scanner.api.internal.IsolatedLauncherProxy.invoke(IsolatedLauncherProxy.java:60)
at jdk.proxy1/jdk.proxy1.$Proxy0.execute(Unknown Source)
at org.sonarsource.scanner.api.EmbeddedScanner.doExecute(EmbeddedScanner.java:189)
at org.sonarsource.scanner.api.EmbeddedScanner.execute(EmbeddedScanner.java:138)
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)\
5

Hi @vadimux,

This error means that your compilation database contains unexpanded response files.

Are you using Cmake? if yes, which version? Have a look at this Unexpanded response file error when using Sonarlint for VSCode - #6 by Abbas. It might be that you changed the CMake version, and those unexpanded response file started appearing.

If you aren’t using CMake, How are you generating the compilation database? Can you share it? I can send you a private message if you prefer to share it privately.

We added support for response file expansion in 6.54 which should be available on SC in a couple of days: [CPP-3572] - Jira.

Thanks,

6

Hi @Abbas thank you for replying, so, I use this command in Bitrise custom script

# Build the project and generate the compile_commands.json file
xcodebuild -workspace "$XCODE_PROJECT" -scheme "$SCHEME" -destination 'generic/platform=iOS' -configuration Release build CODE_SIGN_IDENTITY="" CODE_SIGNING_REQUIRED=NO CODE_SIGN_ENTITLEMENTS="" CODE_SIGNING_ALLOWED=NO  -skipMacroValidation | xcpretty -r json-compilation-database -o compile_commands.json
7

@vadimux,

Did you check if you have unexpanded response files in your compilation database?
If it was working previously, this means that these response files are new and weren’t there before.

Also, you didn’t reply if you are willing to share your compilation database content.

Also, not that the compilation database generated by xcpretty is inaccurate. see [CPP-3665] - Jira.

You can check the recommended way with XCode in this ticket description: [CPP-3987] - Jira

Thanks,

8

sorry @Abbas I can’t find a private message (direct message) button - could you please highlight how can I do this? I’ve prepared compile_commands.json for sharing.

about build-wrapper - [CPP-3987] - Jira I mentioned that I had an issue with macOS 14.2.1 - Build wrapper is not working as expected, Objective C, XCode - #13 by vadimux

thanks

9

Hi @vadimux,

I sent you a private message.

I didn’t refer to build-wrapper. I was referring to the ticket description on how to generate a compilation database:

#add to your xcodebuild command: OTHER_CFLAGS=“$(inherited) -gen-cdb-fragment-path $(PROJECT_DIR)/CompilationDatabase”
xcodebuild clean build arg1 … argN OTHER_CFLAGS=“$(inherited) -gen-cdb-fragment-path $(PROJECT_DIR)/CompilationDatabase”
pushd CompilationDatabase
sed -e ‘1s/^/['$’\n’‘/’ -e ‘$s/,$/'$’\n’‘]/’ *.json > …/compile_commands.json
popd

10

Hi, we are hitting the same exact problem. We have xcpretty generating the compile_commands.json, but it suddenly stopped working yesterday.

I had a look at the cpp library, and it seems the error comes from checks around response files.
In the compile_commands lists command keys with these kind of values:

"/Applications/Xcode-15.3.0.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang \
-Wunguarded-availability \
@/Users/vagrant/Library/Developer/Xcode/DerivedData/redacted.noindex/redacted.build/Debug-iphonesimulator/redacted.Modules.Test.build/Objects-normal/arm64/e6072d4f65d7061329687fe24e3d63a7-common-args.resp"
11

Hi @mcomisso,

but it suddenly stopped working yesterday.

Was there an update to XCode yesterday?

@/Users/vagrant/Library/Developer/Xcode/DerivedData/redacted.noindex/redacted.build/Debug-iphonesimulator/redacted.Modules.Test.build/Objects-normal/arm64/e6072d4f65d7061329687fe24e3d63a7-common-args.resp

These are called response files, they start with @, but they are not supported yet, an initial support was added in the next version that should be available on SC this week.

If it was working before it means that they weren’t generated before and a change happened that started adding them.

12

Thanks for the quick reply!

There was no update to Xcode, we are running on bitrise, stack 15.2.

The failures started at Apr 2, 2:48pm BST, with sonarcloud throwing

java.lang.IllegalStateException: unexpanded response file

in all our pull requests. We’ve been trying to mitigate the issue and updated the stack to 15.3, but without any impact.

13

@mcomisso @vadimux,

I was able to reproduce the issue.

It is fixed by adding this option to xcode CLANG_USE_RESPONSE_FILE=NO

for example:

xcodebuild clean build CLANG_USE_RESPONSE_FILE=NO

Please add this option to your build command to unblock.

If necessary, you can try to remove this option in a week when the support of the response file is deployed on SonarCloud.

There was no change on our side, so there must be a change in the XCode defaults or system settings that led to this.

Thanks,

2 Likes
14

Thank you, I will add it to our flags.

I opened logs on various pull requests trying to match sonarcloud lib versions, and I can confirm there was no change between passing or failing workflows.

Thanks for the help, I’ll post back tomorrow with the results.

1 Like
15

Hi all, yes, the solution from @Abbas works as expected in Bitrise (the report has been provided to SonarCloud correctly). Great and thank you for your effort! Really appreciate.

16

Final Note:

I tested with XCode 15.2, but I couldn’t reproduce the issue.

After further investigation, it turns out that this option CLANG_USE_RESPONSE_FILE was introduced in 15.3 and it defaults to Yes.

2 Likes
18

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.