Sonar-Scanner-MSBuild throwing "org.sonar.core.util.ContextException: Unable to write issue" when generating report

SonarQube Server / Community Build
, ,
1

Version of SonarQube:
Community Edition Version 7.6 (build 21501)

Version of Sonar-Scanner-MSBuild:
sonar-scanner-msbuild-4.6.2.2108-net46

Build environment:
Windows 10
MSBuild.exe from Visual Studio 2017

Version of MSBuild:
Microsoft ® Build Engine version 15.9.21+g9802d43bc3 for .NET Framework
Copyright © Microsoft Corporation. All rights reserved.

I am using the Sonar Scanner for MSBuild to analyze a large .Net project that includes C# and C++.
I am using the Community Edition, so it is ignoring the C++ code and only anlyzing C#, which is fine.

The build is launched from Jenkins, but does not use the Jenkins plugin because the existing legacy build scripts have the calls to MSBuild.exe buried a few layers deep in batch files. So I put the sonar-scanner-msbuild.exe “begin” and “end” calls in the batch file that invokes MSBuild.exe.

The build executes in a ClearCase dynamic view, which is mounted under the M: drive. I have sonar.scm.disabled=true because SQ does not need to interact with the SCM system.

The command line for the sonar-scanner-msbuild “begin” command is this:

“C:\sonar-scanner-msbuild-4.6.2.2108-net46\SonarScanner.MSBuild.exe” begin /k:“ABCD-EF” /d:sonar.verbose=true /d:sonar.scm.disabled=true /d:sonar.host.url=“http://mysonarserver:9000/” /d:sonar.sources=All_ABCD

The “All_ABCD” directory is the directory that contains the master SLN file.

The analysis seems to run with no issues, right up until the point where it is trying to assemble the analysis data into a complete report for upload to the server. Then it throws this exception:

13:15:53.621 INFO: Importing 32 Roslyn reports
13:15:53.855 INFO: ------------------------------------------------------------------------
13:15:53.855 INFO: EXECUTION FAILURE
13:15:53.855 INFO: ------------------------------------------------------------------------
13:15:53.855 INFO: Total time: 1:02.414s
13:15:53.944 INFO: Final Memory: 17M/298M
13:15:53.945 INFO: ------------------------------------------------------------------------
13:15:53.945 ERROR: Error during SonarQube Scanner execution
org.sonar.core.util.ContextException: Unable to write issue | file=M:\jenkins_view\ABCD-EF\01_Build\Automated_Build\Jenkins.sonarqube\out.sonar\scanner-report\issues-470.pb
at org.sonar.core.util.ContextException.of(ContextException.java:125)
at org.sonar.scanner.protocol.output.ScannerReportWriter.appendComponentIssue(ScannerReportWriter.java:87)
at org.sonar.scanner.issue.IssuePublisher.write(IssuePublisher.java:188)
at org.sonar.scanner.issue.IssuePublisher.initAndAddIssue(IssuePublisher.java:74)
at org.sonar.scanner.sensor.DefaultSensorStorage.store(DefaultSensorStorage.java:391)
at org.sonar.api.batch.sensor.issue.internal.DefaultIssue.doSave(DefaultIssue.java:90)
at org.sonar.api.batch.sensor.internal.DefaultStorable.save(DefaultStorable.java:45)
at org.sonarsource.dotnet.shared.plugins.SarifParserCallbackImpl.createIssue(SarifParserCallbackImpl.java:202)
at org.sonarsource.dotnet.shared.plugins.SarifParserCallbackImpl.onIssue(SarifParserCallbackImpl.java:157)
at org.sonarsource.dotnet.shared.sarif.SarifParser10.handleResultFileElement(SarifParser10.java:167)
at org.sonarsource.dotnet.shared.sarif.SarifParser10.handleLocationsElement(SarifParser10.java:139)
at org.sonarsource.dotnet.shared.sarif.SarifParser10.handleIssue(SarifParser10.java:108)
at org.sonarsource.dotnet.shared.sarif.SarifParser10.handleIssues(SarifParser10.java:96)
at org.sonarsource.dotnet.shared.sarif.SarifParser10.accept(SarifParser10.java:66)
at org.sonarsource.dotnet.shared.sarif.SarifParser10.accept(SarifParser10.java:40)
at org.sonarsource.dotnet.shared.plugins.RoslynDataImporter.importRoslynReports(RoslynDataImporter.java:54)
at org.sonarsource.dotnet.shared.plugins.DotNetSensor.executeInternal(DotNetSensor.java:105)
at org.sonarsource.dotnet.shared.plugins.DotNetSensor.execute(DotNetSensor.java:73)
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:408)
at org.sonar.scanner.scan.ProjectScanContainer.scanRecursively(ProjectScanContainer.java:403)
at org.sonar.scanner.scan.ProjectScanContainer.doAfterStart(ProjectScanContainer.java:360)
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:126)
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 sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at 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:111)
at org.sonarsource.scanner.cli.Main.execute(Main.java:75)
at org.sonarsource.scanner.cli.Main.main(Main.java:61)
Caused by: java.io.IOException: The parameter is incorrect
at java.io.FileOutputStream.writeBytes(Native Method)
at java.io.FileOutputStream.write(Unknown Source)
at java.io.BufferedOutputStream.flushBuffer(Unknown Source)
at java.io.BufferedOutputStream.flush(Unknown Source)
at java.io.FilterOutputStream.close(Unknown Source)
at org.sonar.scanner.protocol.output.ScannerReportWriter.appendComponentIssue(ScannerReportWriter.java:86)
… 44 more
Process returned exit code 1
The SonarQube Scanner did not complete successfully
13:15:54.061 Post-processing failed. Exit code: 1

The file mentioned in the exception message (issues-470.pb) exists, but is zero bytes.
There are three “issues-xxx.pb” files in that directory, and all of them are zero bytes.
There are several hundred “symbols-xxx.pb” files in that directory, with sizes ranging from 1kb to 12kb.

Based on the “java.io.IOException: The parmeter is incorrect” message, I thought it might be an issue with file encoding. I have tried a few different values for sonar.sourceEncoding, including utf-8 and Windows-1252, and that does not change the behavior.

I also ran with sonar.scanner.dumpToFile, and the exception does not occur, because the dry-run behavior of this parameter means that it never tries to assemble the report.

3

Hi @drosen02 - welcome to the community!

Firstly, you should not specify sonar.sources if you are using the Scanner for MSBuild (the scanner will automatically set this value based on the files referenced in the projects).
However, I wouldn’t expect that to cause the error.

Can you tell from the log which of the Roslyn json files is being processed when the failure occurs?
Which Roslyn analyzers are you running?

4

Duncan,

Thank you for your response. I took the sonar.sources parameter out and ran it again, and I’m still seeing the same behavior. The exception message appears five separate times in the console output, each time for a different “issues-xxx.pb” file.

I am able to see (from analysis.log) what the JSON files are for the affected modules.

The quality profiles for both C# and XML are “Sonar way”. I’m not sure if that’s the same as the “Roslyn analyzers” that you asked about.

Of the five times the exception occurs, four of them occur while applying the same rule (S125 - Remove this commented out code) to either an XML or XSD file, each time preceded by the same “Unable to execute rule” message. The first three are on different files in the same module, and the fourth is on a file in a different module.

The JSON files for each of these modules contain multiple S125 warnings under “results” for other files in the module.

Here are the error and exception messages:

12:43:29.485 ERROR: Unable to execute rule xml:S125 on file:///M:/jenkins_view/ABCD-EF/05_Source_Code/ABCD/ABCD.Component.Configuration/Configuration/ABCDDelayMeasurementsMITE.xml
org.sonar.core.util.ContextException: Unable to write issue | file=M:\jenkins_view\ABCD-EF\01_Build\Automated Build.sonarqube\out.sonar\scanner-report\issues-385.pb

12:43:29.651 ERROR: Unable to execute rule xml:S125 on file:///M:/jenkins_view/ABCD-EF/05_Source_Code/ABCD/ABCD.Component.Configuration/Configuration/ABCDMachineConfiguration.xml
org.sonar.core.util.ContextException: Unable to write issue | file=M:\jenkins_view\ABCD-EF\01_Build\Automated Build.sonarqube\out.sonar\scanner-report\issues-388.pb

12:43:30.060 ERROR: Unable to execute rule xml:S125 on file:///M:/jenkins_view/ABCD-EF/05_Source_Code/ABCD/ABCD.Component.Configuration/Configuration/ABCDSchema.xsd
org.sonar.core.util.ContextException: Unable to write issue | file=M:\jenkins_view\ABCD-EF\01_Build\Automated Build.sonarqube\out.sonar\scanner-report\issues-394.pb

sonar.cs.roslyn.reportFilePath=M:\jenkins_view\ABCD-EF\05_Source_Code\ABCD\ABCD.GUI.ScriptEngine\bin\Debug\ABCD.GUI.ScriptEngine.exe.RoslynCA.json

12:43:31.786 ERROR: Unable to execute rule xml:S125 on file:///M:/jenkins_view/ABCD-EF/05_Source_Code/ABCD/ABCD.GUI.ScriptEngine/ABCDSchema.xsd
org.sonar.core.util.ContextException: Unable to write issue | file=M:\jenkins_view\ABCD-EF\01_Build\Automated Build.sonarqube\out.sonar\scanner-report\issues-104.pb

The final exception occurs at the end, when it tries to import all of the Roslyn reports:

12:43:52.958 INFO: Importing 25 Roslyn reports
12:43:53.197 INFO: ------------------------------------------------------------------------
12:43:53.197 INFO: EXECUTION FAILURE
12:43:53.197 INFO: ------------------------------------------------------------------------
12:43:53.197 INFO: Total time: 40.256s
12:43:53.240 INFO: Final Memory: 14M/54M
12:43:53.240 INFO: ------------------------------------------------------------------------
12:43:53.240 ERROR: Error during SonarQube Scanner execution
org.sonar.core.util.ContextException: Unable to write issue | file=M:\jenkins_view\ABCD-EF\01_Build\Automated Build.sonarqube\out.sonar\scanner-report\issues-257.pb

All of the files noted in the exception messages exist, but are zero bytes, and those are the only “issues-xxx.pb” files that I see in the directory. There are hundreds of “symbols-yyy.pb” and “syntax-highlighting-zzz.pb” files in the directory that do contain data, so writing to that directory is possible.

Thanks again for your help.
David

5

@duncanp I believe I found the root cause of the issue. Long story short, the scanner appears to have issues when running inside a ClearCase dynamic view. I switched to a snapshot view (which is a local workspace on the build machine), and all of the problems went away, including the exceptions when processing the XML, and the exception at the end when assembling the full report.

Thanks for your assistance.

David

6

Thanks for the update @drosen02. I don’t think I’d ever have worked that out from the log files :wink:

Cheers,
Duncan