Error during SonarScanner execution java.lang.NullPointerException

Must-share information (formatted with Markdown):

  • which versions are you using:
    • SonarQube 9.5 Enterprise Edition
    • sonar-scanner
  • what are you trying to achieve
    • Scan C++ code with compilation database stored in compile_commands.json
  • what have you tried so far to achieve this
    • It works, but on some builds sonar-scanner fails with a null pointer exception.

We get the following output:

ERROR: Error during SonarScanner execution
    at com.sonar.cpp.plugin.CFamilySensor.lambda$save$20(
    at java.base/java.util.Spliterators$ArraySpliterator.forEachRemaining(Unknown Source)
    at java.base/$Head.forEach(Unknown Source)
    at com.sonar.cpp.plugin.CFamilySensor.process(
    at com.sonar.cpp.plugin.CFamilySensor.lambda$process$17(
    at com.sonar.cpp.plugin.CompileCommandsReader.readCaptures(
    at com.sonar.cpp.plugin.CFamilySensor.process(
    at com.sonar.cpp.plugin.CFamilySensor.process(
    at com.sonar.cpp.plugin.CFamilySensor.execute(
    at org.sonar.scanner.sensor.AbstractSensorWrapper.analyse(
    at org.sonar.scanner.sensor.ModuleSensorsExecutor.execute(
    at org.sonar.scanner.sensor.ModuleSensorsExecutor.execute(
    at org.sonar.scanner.scan.SpringModuleScanContainer.doAfterStart(
    at org.sonar.core.platform.SpringComponentContainer.startComponents(
    at org.sonar.core.platform.SpringComponentContainer.execute(

We’re trying to scan a C++ project using a compile_commands.json. This error is definitely an error in the sonar-scanner itself, since whatever array it’s trying to index into is unsound.

We need this to be resolved, since currently about 20% of builds are failing this way.

Welcome to the community @Carl!

For the purpose of investigation could you please provide the full content of the sonar-scanner-log with debug enabled (-X passed to sonar-scanner invocation) and your compilation database file (compile-commands.json)? If you think this file contains private information, let us know, and we’ll send you a private message that will allow you to send it privately.

Thank you for your answer. The file indeed contains private info and I cannot share it.

This is a bit of an educated guess, but could you please check if setting the following property (in or in the command line using -Dsonar.analysisCache.enabled=false) will fix the crash for you:


Since this takes some time to run on our project I can’t confirm this yet. But we’ve already started clearing the analysisCache (since we still want to create a fresh one then to keep the compile times from becoming prohibitive), and it seems to usually work after that.

However this still means that the sonar-scanner is not checking properly what it’s indexing into here, since even if something else is cached it shouldn’t take down the whole build.

We’ve also tried using the new server-side caching due to the deprecation message, but no matter how many runs we do we always get the empty server cache warning.

We understand and acknowledge that there is an issue in the sonar-scanner that causes some projects to fail your analysis, and thus greatly appreciate your report. However, this issue does not reproduce on any of our internal tests (we analyze a lot of projects daily with cache enabled), and the line in the report points to a place that is never expected to be null. Thus to find the root cause and fix the issue we need more information.

This is why I asked you to privately share the analysis log (PM was already sent), and to perform some tests that would either confirm or eliminate some of the possible root causes.

After adding the --debug or -X flag I got a different failure. I removed the identifiable file names

2022-08-10T14:03:49.6985684Z 14:03:49.697 DEBUG: [pool-3-thread-30] /usr/include/x86_64-linux-gnu/qt5/QtCore/qglobal.h:1187 "You must build your code with position independent code if Qt was built with -reduce-relocations. "         "Compile your code with -fPIC (-fPIE is not enough)."
2022-08-10T14:03:49.7002761Z 14:03:49.699 DEBUG: [pool-3-thread-30] /src/absolute/path/to/REDACTED.cpp '../include/relative/path/to/OTHER_REDACTED.cpp' file not found
2022-08-10T14:03:49.7348076Z 14:03:49.733 INFO: ------------------------------------------------------------------------
2022-08-10T14:03:49.7348630Z 14:03:49.733 INFO: EXECUTION FAILURE
2022-08-10T14:03:49.7349203Z 14:03:49.733 INFO: ------------------------------------------------------------------------
2022-08-10T14:03:49.7349629Z 14:03:49.734 INFO: Total time: 1:44.463s
2022-08-10T14:03:49.8107507Z 14:03:49.809 INFO: Final Memory: 146M/616M
2022-08-10T14:03:49.8109488Z 14:03:49.809 INFO: ------------------------------------------------------------------------
2022-08-10T14:03:49.8110145Z 14:03:49.809 ERROR: Error during SonarScanner execution
2022-08-10T14:03:49.8110929Z java.lang.IllegalStateException:
2022-08-10T14:03:49.8111705Z 	at com.sonar.cpp.plugin.cache.CacheInImpl.readExternalIssuesCacheName(
2022-08-10T14:03:49.8112382Z 	at com.sonar.cpp.plugin.cache.CacheInImpl.query(
2022-08-10T14:03:49.8113014Z 	at com.sonar.cpp.plugin.CFamilySensor.process(
2022-08-10T14:03:49.8113633Z 	at com.sonar.cpp.plugin.CFamilySensor.lambda$process$17(
2022-08-10T14:03:49.8114367Z 	at com.sonar.cpp.plugin.CompileCommandsReader.readCaptures(
2022-08-10T14:03:49.8115411Z 	at com.sonar.cpp.plugin.CFamilySensor.process(
2022-08-10T14:03:49.8116009Z 	at com.sonar.cpp.plugin.CFamilySensor.process(
2022-08-10T14:03:49.8116604Z 	at com.sonar.cpp.plugin.CFamilySensor.execute(
2022-08-10T14:03:49.8117246Z 	at org.sonar.scanner.sensor.AbstractSensorWrapper.analyse(
2022-08-10T14:03:49.8117924Z 	at org.sonar.scanner.sensor.ModuleSensorsExecutor.execute(
2022-08-10T14:03:49.8118617Z 	at org.sonar.scanner.sensor.ModuleSensorsExecutor.execute(
2022-08-10T14:03:49.8119341Z 	at org.sonar.scanner.scan.SpringModuleScanContainer.doAfterStart(
2022-08-10T14:03:49.8120099Z 	at org.sonar.core.platform.SpringComponentContainer.startComponents(
2022-08-10T14:03:49.8120828Z 	at org.sonar.core.platform.SpringComponentContainer.execute(
2022-08-10T14:03:49.8121548Z 	at org.sonar.scanner.scan.SpringProjectScanContainer.scan(
2022-08-10T14:03:49.8122296Z 	at org.sonar.scanner.scan.SpringProjectScanContainer.scanRecursively(
2022-08-10T14:03:49.8123064Z 	at org.sonar.scanner.scan.SpringProjectScanContainer.doAfterStart(
2022-08-10T14:03:49.8123801Z 	at org.sonar.core.platform.SpringComponentContainer.startComponents(
2022-08-10T14:03:49.8124537Z 	at org.sonar.core.platform.SpringComponentContainer.execute(
2022-08-10T14:03:49.8125271Z 	at org.sonar.scanner.bootstrap.SpringGlobalContainer.doAfterStart(
2022-08-10T14:03:49.8126016Z 	at org.sonar.core.platform.SpringComponentContainer.startComponents(
2022-08-10T14:03:49.8126735Z 	at org.sonar.core.platform.SpringComponentContainer.execute(
2022-08-10T14:03:49.8127381Z 	at org.sonar.batch.bootstrapper.Batch.doExecute(
2022-08-10T14:03:49.8127935Z 	at org.sonar.batch.bootstrapper.Batch.execute(
2022-08-10T14:03:49.8128599Z 	at org.sonarsource.scanner.api.internal.batch.BatchIsolatedLauncher.execute(
2022-08-10T14:03:49.8129261Z 	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
2022-08-10T14:03:49.8129839Z 	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
2022-08-10T14:03:49.8130420Z 	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
2022-08-10T14:03:49.8131086Z 	at java.base/java.lang.reflect.Method.invoke(Unknown Source)
2022-08-10T14:03:49.8131702Z 	at org.sonarsource.scanner.api.internal.IsolatedLauncherProxy.invoke(
2022-08-10T14:03:49.8132299Z 	at com.sun.proxy.$Proxy0.execute(Unknown Source)
2022-08-10T14:03:49.8132852Z 	at org.sonarsource.scanner.api.EmbeddedScanner.doExecute(
2022-08-10T14:03:49.8133490Z 	at org.sonarsource.scanner.api.EmbeddedScanner.execute(
2022-08-10T14:03:49.8134082Z 	at org.sonarsource.scanner.cli.Main.execute(
2022-08-10T14:03:49.8134617Z 	at org.sonarsource.scanner.cli.Main.execute(
2022-08-10T14:03:49.8135138Z 	at org.sonarsource.scanner.cli.Main.main(
2022-08-10T14:03:49.8135559Z Caused by:
2022-08-10T14:03:49.8136093Z 	at com.sonar.cpp.plugin.cache.CacheInImpl.readExternalIssuesCacheName(
2022-08-10T14:03:49.8136879Z 	at com.sonar.cpp.plugin.cache.CacheInImpl.readExternalIssuesCacheName(
2022-08-10T14:03:49.8137279Z 	... 35 more

Could you please provide some details on your configuration? We have two different errors reported in this thread:

  1. java.lang.NullPointerException in this post
  2. in this post

Did both of these errors appear on the same configuration or on different ones? Could you provide more details on your setting, especially if and what kind of cache was used? You have mentioned that you tried to use both “SonarQube server-side cache” and “filesystem cache”.

Finally, where you able to confirm that any of above issues appears with cache disabled?

Yes, same configs, same system version, same SonarQube version, same sonar-scanner version. Different compile_commands and build and cache though.

With empty cache (which is similar to cache disabled I guess) I can’t confirm any failures yet.

We’re currently using the deprecated caching strategy, because neither the new filesystem cache, nor the server side cache appear to work. The sonar-scanner never finds a cache.

Hi @Carl ,

I’ll follow up on this topic. In order to understand what is going wrong let’s try to focus on one use case.

For your information, the deprecated caching strategy is the same as the new filesystem cache.

Let’s focus on the “deprecated caching strategy”, are you facing issues with it?

Hi @Carl ,

did you manage to solve your issue?

By having more frequent builds these errors happen less often now, which means that this is a cache invalidation issue, however they are not solved. When clearing the cache (not good, takes too long to analyze stuff), it usually doesn’t fail.

I’m guessing somebody should maybe analyze the code in sonar-scanner and look for ways that an older cache could lead to null pointers and buffer overflows. It seems not all corner cases are considered.

I assume the cache is per translation unit. One measure to mitigate this issue almost completely would build every translation unit with cache, and catch these failures, and then clear the cache only for this translation unit. That way we would only need to redo that small part of the whole project analysis. Barring solving all programming errors in the sonar-scanner this should give us 90% of the benefit for 10% of the effort.