Exception when running SonarCloudAnalyze@3

SonarQube Server / Community Build Plugin Development
1

Hello

We have code that has been analyzed by SonarCloud fine in the past, but after an issues fixing cycle, we now get a crash in the SonarCloudAnalyze task.

We use C++.

We get an exception with the suggestion to send a file to support, so this file is attached (The file was renamed from tar.xz to support the upload filter)

If you require addition information, please let me know.

Thank you

sonar-cfamily-reproducer.tarxz (533.9 KB)

6

Hello @PPRiphagen, and thanks for your patience.

I’ve been looking at the reproducer and can reproduce the issue on my end. I had a look at the code to see if there was something odd about it that you could easily change on your end to workaround the issue until we fix it – but it looks pretty standard so no “luck” there.

I’ve raised an internal ticket that we’ll aim to fix for our next release. A big thanks for having shared the reproducer with us!

In the meantime, I assume the overall analysis is working well. If that’s not the case, please let us know so we can help you disable, on this specific file, the part of the analysis that lead to the crash.

Cheers,
Marco

7

Hello Marco

Thank you very much for your analysis. Apart from this issue we don’t have problems.

I would be helpful if you can provide the way for disabling analysis for the function SonarCloud is having issues with.

Then we will be looking forward to the next release with this issue fixed.

Thank you,

Patrick

8

My apologies for the slow answer.

Because multiple functions lead to this crash, we cannot simply disable one.

Now, you have two options.

  1. Disabling the analysis on that particular file. It is possible, but I would suggest not doing this since the analysis is capable of recovering from the crash. This way, you won’t have to update your configuration when we release the fix.
  2. Because the crash is happening in our symbolic-execution engine, you can disable only symbolic-execution rules on that particular file. This should enable you to get analysis result from our other kinds of rules. I would ponder whether this is a file you modify often or not. Depending on that, you may want to use the following option: add sonar.cfamily.internal.symbolicExecution.exclusions=C:/a/1/s/common/src/sparsematrix.cpp to your analysis properties

Refer to Configuration overview | Sonar Documentation if needed.

I hope this helps.

9

Hello Marco

I tried adding this option, but the scanner does not seem to take this into account?

sonar-cfamily-reproducer (2).tarxz (533.9 KB)

Thank you

Patrick

10

Hi @PPRiphagen,

That’s odd. The path of the file to be excluded has to specified using `sonar.cfamily.internal.symbolicExecution.exclusions` exactly as it appears in the logs, i.e., `sonar.cfamily.internal.symbolicExecution.exclusions=C:/a/5/s/common/src/sparsematrix.cpp` as per the latest reproducer that you sent.

If the analyzer successfully recognizes the exclusion, you should see a warning message like `Rules with ‘symbolic-execution’ tag are disabled for: <YOUR_FILE>` in the logs.

In the previous logs, the file was located at `C:/a/1/s/common/src/sparsematrix.cpp*`.* May I ask how you have specified the exclusion? Does the path change from analysis run to analysis run?

Cheers,
Philipp

11

Hi Philipp

The path can indeed change per run, that’s why I use a devops variable, just like I do with other sonar properties:

Additional properties that will be passed to the scanner,

      # Put one key=value per line, example:
      # sonar.exclusions=\*\*/\*.bin
      sonar.verbose=true
      sonar.projectBaseDir=$(System.DefaultWorkingDirectory)
      sonar.cfamily.internal.symbolicExecution.exclusions=$(System.DefaultWorkingDirectory)/common/src/sparsematrix.cpp
      sonar.cfamily.compile-commands=$(BUILD_WRAPPER_OUTPUTDIR)/compile_commands.json
      sonar.coverageReportPaths=$(System.DefaultWorkingDirectory)/coverage_all_unittests.xml
13

Hi @PPRiphagen,

I said something wrong in my previous message: the analysis is not recovering and you indeed need to use an extra property for that; which you’ll need to remove once the bug is fixed.

Regarding

sonar.cfamily.internal.symbolicExecution.exclusions=$(System.DefaultWorkingDirectory)/common/src/sparsematrix.cpp

Can you print the interpreted content of the file holding this line? I’m wondering if $(System.DefaultWorkingDirectory) expands to a path with backslashes while the analyzer is expecting exactly C:/a/5/s/common/src/sparsematrix.cpp, i.e., with forward-slashes. Or maybe the case is not the same?

Alternatively, you can exclude that specific file from the analysis using sonar.exclusions: Excluding based on path-matching patterns | Sonar Documentation This property is more general and allows pattern matching and paths relative to the sonar.projectBaseDir property.

I hope this helps. Let us know if you still have problems.