Should SonarScanner be more robust handling "line X out of range" of e.g. jacoco?

SonarQube
1

Hi,

today our SonarScanner run failed once more because of JaCoCo reporting an error “line X out of range” (see exception stacktrace below). This means the whole execution failed because of 1 file not being correct.
Could the SonarScanner be more robust in handling that scenario without failing the complete run? (e.g. just logging an error)
Or is it rather the responsibility of the JaCoCo part?

Greetings
Holger

INFO: EXECUTION FAILURE
INFO: ------------------------------------------------------------------------
INFO: Total time: 1:31:17.563s
INFO: Final Memory: 289M/7664M
INFO: ------------------------------------------------------------------------
ERROR: Error during SonarQube Scanner execution
java.lang.IllegalStateException: Line 116 is out of range in the file projects/main/plugins/aquintos.queryresulttable/src/aquintos/queryresulttable/QueryTableEditorLabelUpdater.java (lines: 113)
at org.sonar.api.internal.google.common.base.Preconditions.checkState(Preconditions.java:197)
at org.sonar.api.batch.sensor.coverage.internal.DefaultCoverage.validateLine(DefaultCoverage.java:93)
at org.sonar.api.batch.sensor.coverage.internal.DefaultCoverage.lineHits(DefaultCoverage.java:81)
at org.sonar.plugins.jacoco.UnitTestAnalyzer.analyzeFile(UnitTestAnalyzer.java:247)
at org.sonar.plugins.jacoco.UnitTestAnalyzer.readExecutionData(UnitTestAnalyzer.java:132)
at org.sonar.plugins.jacoco.UnitTestAnalyzer.analyse(UnitTestAnalyzer.java:95)
at org.sonar.plugins.jacoco.JaCoCoSensor.execute(JaCoCoSensor.java:77)
at org.sonar.scanner.sensor.SensorWrapper.analyse(SensorWrapper.java:53)
at org.sonar.scanner.phases.SensorsExecutor.executeSensor(SensorsExecutor.java:88)
at org.sonar.scanner.phases.SensorsExecutor.execute(SensorsExecutor.java:82)
at org.sonar.scanner.phases.SensorsExecutor.execute(SensorsExecutor.java:68)
at org.sonar.scanner.phases.AbstractPhaseExecutor.execute(AbstractPhaseExecutor.java:88)
at org.sonar.scanner.scan.ModuleScanContainer.doAfterStart(ModuleScanContainer.java:180)
at org.sonar.core.platform.ComponentContainer.startComponents(ComponentContainer.java:135)
at org.sonar.core.platform.ComponentContainer.execute(ComponentContainer.java:121)
at org.sonar.scanner.scan.ProjectScanContainer.scan(ProjectScanContainer.java:288)
at org.sonar.scanner.scan.ProjectScanContainer.scanRecursively(ProjectScanContainer.java:283)
at org.sonar.scanner.scan.ProjectScanContainer.doAfterStart(ProjectScanContainer.java:261)
at org.sonar.core.platform.ComponentContainer.startComponents(ComponentContainer.java:135)
at org.sonar.core.platform.ComponentContainer.execute(ComponentContainer.java:121)
at org.sonar.scanner.task.ScanTask.execute(ScanTask.java:48)
at org.sonar.scanner.task.TaskContainer.doAfterStart(TaskContainer.java:84)
at org.sonar.core.platform.ComponentContainer.startComponents(ComponentContainer.java:135)
at org.sonar.core.platform.ComponentContainer.execute(ComponentContainer.java:121)
at org.sonar.scanner.bootstrap.GlobalContainer.executeTask(GlobalContainer.java:121)
at org.sonar.batch.bootstrapper.Batch.doExecuteTask(Batch.java:116)
at org.sonar.batch.bootstrapper.Batch.executeTask(Batch.java:111)
at org.sonarsource.scanner.api.internal.batch.BatchIsolatedLauncher.execute(BatchIsolatedLauncher.java:63)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
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:233)
at org.sonarsource.scanner.api.EmbeddedScanner.runAnalysis(EmbeddedScanner.java:151)
at org.sonarsource.scanner.cli.Main.runAnalysis(Main.java:123)
at org.sonarsource.scanner.cli.Main.execute(Main.java:77)
at org.sonarsource.scanner.cli.Main.main(Main.java:61)
ERROR:
ERROR: Re-run SonarQube Scanner using the -X switch to enable full debug logging.
ERROR: SonarQube scanner exited with non-zero code: 1

2

Hi Holger,

Well what the error itself means is that the JaCoCo reports contains coverage data for a line that is not found in the corresponding source file. So I would more specifically put the responsibility on the overall Continuous Integration chain: at any point in time it’s important that the coverage reports present locally correspond precisely to the actual source files analyzed locally.

If any slightest mismatch (e.g. source files changed after coverage data was computed) then failing is the only viable strategy, otherwise you run the risk of having totally incorrect data reported and tracked by your team (in that respect, silent failure or incorrect data is worst than any failure at all).

3

Hi Nicolas,

Thanks for the answer. I think you are right.
Currently we cannot guarantee that the JaCoCo report corresponds precisely to the source files that are analyzed locally. We will work on that.

Greetings Holger

1 Like
4

Please forgive me, if this is a dumb question, but how would I disable JaCoCo reports? I had a look at the settings in the administration page, but there is no single setting.
The rules common-java:InsufficientLineCoverage and common-java:InsufficientBranchCoverage are disabled, yet the JaCoCoSensor is still active. I could exclude all files from coverage analysis or point sonar.jacoco.reportPaths to some non-existing path but this solution strikes me as not optimal.