Error occurred when analyze C++ files based on Bazel 5.0 in SonarQube 9.9

I deployed SonarQube 9.9 by zip files on Windows. Everything of SonarQube is configured correctly, including build-wrapper and sonar-scanner. However, when I execute sonar-scanner to analyze C++ source code based on Bazel 5.0, an error occured from CFamilySensor plugin.

Env:

  • Enterprise Edition
  • Version 9.9 (build 65466) and Version 9.9.1 (build 69595)
  • CFamily plugin version: 6.41.0.60884

The following is the error log.

00:14:14.256249700 ERROR 
An error occurred while analyzing the following compilation unit: 
  C:/users/zao/Repositories/test/tlmTransaction/tlmTransaction.cpp
A file named "sonar-cfamily-reproducer.zip" has been generated to help the problem investigation.
Please contact SonarSource support providing the following file to help improving the analyzer:
  C:\Users\zao\Repositories\test\sonar-cfamily-reproducer.zip

java.lang.IllegalStateException: 
An error occurred while analyzing the following compilation unit: 
  C:/users/zao/Repositories/test/tlmTransaction/tlmTransaction.cpp
A file named "sonar-cfamily-reproducer.zip" has been generated to help the problem investigation.
Please contact SonarSource support providing the following file to help improving the analyzer:
  C:\Users\zao\Repositories\test\sonar-cfamily-reproducer.zip

	at com.sonar.cpp.plugin.CFamilySensor.process(CFamilySensor.java:442)
	at com.sonar.cpp.plugin.CFamilySensor.execute(CFamilySensor.java:215)
	at org.sonar.scanner.sensor.AbstractSensorWrapper.analyse(AbstractSensorWrapper.java:64)
	at org.sonar.scanner.sensor.ModuleSensorsExecutor.execute(ModuleSensorsExecutor.java:88)
	at org.sonar.scanner.sensor.ModuleSensorsExecutor.execute(ModuleSensorsExecutor.java:64)
	at org.sonar.scanner.scan.SpringModuleScanContainer.doAfterStart(SpringModuleScanContainer.java:82)
	at org.sonar.core.platform.SpringComponentContainer.startComponents(SpringComponentContainer.java:188)
	at org.sonar.core.platform.SpringComponentContainer.execute(SpringComponentContainer.java:167)
	at org.sonar.scanner.scan.SpringProjectScanContainer.scan(SpringProjectScanContainer.java:403)
	at org.sonar.scanner.scan.SpringProjectScanContainer.scanRecursively(SpringProjectScanContainer.java:399)
	at org.sonar.scanner.scan.SpringProjectScanContainer.doAfterStart(SpringProjectScanContainer.java:368)
	at org.sonar.core.platform.SpringComponentContainer.startComponents(SpringComponentContainer.java:188)
	at org.sonar.core.platform.SpringComponentContainer.execute(SpringComponentContainer.java:167)
	at org.sonar.scanner.bootstrap.SpringGlobalContainer.doAfterStart(SpringGlobalContainer.java:137)
	at org.sonar.core.platform.SpringComponentContainer.startComponents(SpringComponentContainer.java:188)
	at org.sonar.core.platform.SpringComponentContainer.execute(SpringComponentContainer.java:167)
	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: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)

And a more important point is that I also tested in other versions with the same project and sonar-project.properties. The result is
- Version 8.9.10 works
- Version 9.8 works
- Version 9.9 doesn’t work
- Version 9.9.1 doesn’t work
- Version 10.0 works

Thus, this should be a critical bug in version 9.9.x. As the LTS version, this bug need to be fixed ASAP.
Thank you!

Hi,

Thanks for your thorough investigation.

Unfortunately, the fix is not likely to be backported to SonarQube 9.9 LTS, since this probably wouldn’t be considered a critical bug in that context.

 
Ann

Why it is not critical? All C++ projects cannot be analyzed by SonarQube v9.9. As a LTS release, this bug will influence thousands of C++ projects.

Hi @KevinAo22,

We aren’t aware of any change related to Bazel between 9.9 and 10.
Can you share the reproducer file so we can investigate the crash and identify the ticket that fixed it?
Let me know if you prefer to share it privately.

Did you try to exclude C:/users/zao/Repositories/test/tlmTransaction/tlmTransaction.cpp from the analysis with 9.9 to check if the issue is local to one file?

Thanks,

Hi,

I tried to exclude tlmTransaction.cpp from the analysis, however, the error still occurred on another cpp file.

How can I share the reproducer file with you?

@KevinAo22, I sent you a PM.

Sent it.

Hi @KevinAo22 and thanks for raising this point.

We are looking into whether the fix can be merged into the LTS. In the meantime, you should be able to fix this issue by doing one of the following:

  • replacing the two nested namespaces in tlmTransaction/config.h with the C++17 equivalent
namespace A::B {
}
  • adding a carriage return at the end of tlmTransaction/config.h
  • upgrading your SonarQube version to 10.0
  • disabling rule S5812
4 Likes

I tried all these suggestions. Only upgrading SonarQube 10.0 works like I mentioned before in the first message, the others still occur the same error and cannot fix the issue. Plz help me re-check the root cause. There may be other bugs.
I have sent the new reproducer file to Abbas.

After I deleted this line,
writeFile << std::setw(4) << transJson << std::endl;
the error doesn’t happen again, even if I didn’t follow your suggestions, such as disable rule S5812. Why?

Hi @KevinAo22 ,
Indeed, you are having another unrelated bug on the line you identified. Sorry about that.
You can fix this new problem by either disabling S6495 or changing your std::endl with \n.

1 Like

It works fine now. Thank you!

1 Like

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