Sonar-scanner cpp fails with NullPointerException

SonarQube Server / Community Build
,
1

I’ve been trying to get SonarQube to scan our big C/C++ project, but it keeps crashing with a NullPointerException during the code analysis

The end of the sonar-scanner output

13:30:37.312 INFO: [pool-3-thread-1] /usr/src/csw_bgan_ut_rm/modules/applications/bgan_ut_rm/psu/common/src/watchdog.c
13:30:37.363 DEBUG: [pool-3-thread-1] /usr/src/csw_bgan_ut_rm/modules/applications/bgan_ut_rm/psu/common/src/watchdog.c:22 use of undeclared identifier 'CCP'
13:30:37.363 DEBUG: [pool-3-thread-1] /usr/src/csw_bgan_ut_rm/modules/applications/bgan_ut_rm/psu/common/src/watchdog.c:22 use of undeclared identifier 'CCP_IOREG_gc'
13:30:37.363 DEBUG: [pool-3-thread-1] /usr/src/csw_bgan_ut_rm/modules/applications/bgan_ut_rm/psu/common/src/watchdog.c:23 use of undeclared identifier 'WDT'
13:30:37.363 DEBUG: [pool-3-thread-1] /usr/src/csw_bgan_ut_rm/modules/applications/bgan_ut_rm/psu/common/src/watchdog.c:23 use of undeclared identifier 'WDT_PER_8KCLK_gc'
13:30:37.364 DEBUG: [pool-3-thread-1] /usr/src/csw_bgan_ut_rm/modules/applications/bgan_ut_rm/psu/common/src/watchdog.c:23 use of undeclared identifier 'WDT_ENABLE_bm'
13:30:37.364 DEBUG: [pool-3-thread-1] /usr/src/csw_bgan_ut_rm/modules/applications/bgan_ut_rm/psu/common/src/watchdog.c:23 use of undeclared identifier 'WDT_CEN_bm'
13:30:37.365 DEBUG: Probing compiler: [/remote/build-archive/Build-bganut-buildroot-2016/0074/sdk-native/usr/bin/toolchain-wrapper, -x, c++, --sysroot=/remote/build-archive/Build-bganut-buildroot-2016/0074/sdk-native/usr/i686-thrane-linux-gnu/sysroot, -v, -dM, -E, -]
13:30:37.367 INFO: [pool-3-thread-1] /usr/src/csw_bgan_ut_rm/modules/applications/bgan_ut_rm/bp/adu_manager_if/src/adu_manager_if.cpp
13:30:37.376 DEBUG: stdout:

13:30:37.376 DEBUG: stderr:
/remote/build-archive/Build-bganut-buildroot-2016/0074/sdk-native/usr/bin/toolchain-wrapper.br_real: No such file or directory

13:30:46.032 INFO: ------------------------------------------------------------------------
13:30:46.033 INFO: EXECUTION FAILURE
13:30:46.033 INFO: ------------------------------------------------------------------------
13:30:46.033 INFO: Total time: 2:12.190s
13:30:46.179 INFO: Final Memory: 23M/84M
13:30:46.179 INFO: ------------------------------------------------------------------------
13:30:46.180 ERROR: Error during SonarQube Scanner execution
java.lang.NullPointerException
        at com.sonar.cpp.analyzer.StdFlags.fromCppMacros(StdFlags.java:23)
        at com.sonar.cpp.analyzer.ClangDriver.onCapture(ClangDriver.java:349)
        at com.sonar.cpp.plugin.CFamilySensor.process(CFamilySensor.java:273)
        at com.sonar.cpp.plugin.CFamilySensor.execute(CFamilySensor.java:205)
        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:82)
        at org.sonar.core.platform.ComponentContainer.startComponents(ComponentContainer.java:136)
        at org.sonar.core.platform.ComponentContainer.execute(ComponentContainer.java:122)
        at org.sonar.scanner.scan.ProjectScanContainer.scan(ProjectScanContainer.java:400)
        at org.sonar.scanner.scan.ProjectScanContainer.scanRecursively(ProjectScanContainer.java:395)
        at org.sonar.scanner.scan.ProjectScanContainer.doAfterStart(ProjectScanContainer.java:358)
        at org.sonar.core.platform.ComponentContainer.startComponents(ComponentContainer.java:136)
        at org.sonar.core.platform.ComponentContainer.execute(ComponentContainer.java:122)
        at org.sonar.scanner.bootstrap.GlobalContainer.doAfterStart(GlobalContainer.java:141)
        at org.sonar.core.platform.ComponentContainer.startComponents(ComponentContainer.java:136)
        at org.sonar.core.platform.ComponentContainer.execute(ComponentContainer.java:122)
        at org.sonar.batch.bootstrapper.Batch.doExecute(Batch.java:73)
        at org.sonar.batch.bootstrapper.Batch.execute(Batch.java:67)
        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)

I have attached the full output. Unfortunately, I can’t upload the build-wrapper files, as they are too large (JSON is ~40MB, log is ~150MB)

Version info:
SonarQube: v7.9.1 (build 27448)
SonarQube Scanner: v4.0.0.1744
SonarCFamily Plugin: v6.3 (build 11371)

sonar-scanner-output.txt (1.6 MB)

2

Hi @RuneTS,

we fail because /remote/build-archive/Build-bganut-buildroot-2016/0074/sdk-native/usr/bin/toolchain-wrapper.br_real it is not available during analysis, do you delete it between build and analysis?

3

Sorry for the late response.

The problem is that the toolchain-wrapper can’t be called using it’s own name, we have several links to the binary, maskerading as e.g. g++, but it seems like the analyzer calls it with the toolchain-wrapper name.
Is there any way we can stop it from looking up the names target, and just make it call using the right name?

4

Hi @RuneTS,

Unfortunately you are hit by this current limitation: CPP-1853, you could try to change your setup to use intermediate bash scripts instead of symlinks but it complicates and requires to change your setup.

5

Ahh! Thanks. We’ll see if we can fix this on our end :slight_smile:

1 Like
6

Hi @RuneTS

I have the same issue. Could you solve it? How did you do it?

7

Hi @x.michel,

I managed to solve it by changing our symbolic links to hard links. This works for us, since our links always are in the same folder as the target, but if you link to something on another partition, this won’t work.

So: yes we managed to fix it, but our solution might not work for you.

I used this to convert the links

for link in $(find -type l -exec ls -l {} \; | grep toolchain-wrapper | awk '{print $9}'); do 
  ln -f toolchain-wrapper ${link}; 
done;

Hope this helps :slight_smile:

2 Likes
8

Hi @RuneTS and @x.michel,

FYI the issue mentioned in this thread has been fixed in CPP-2459 and released as part of SonarCFamily 6.8.