Possible exception during analysis

jaudiger commented 2 years ago

I encountered this exception during the analysis:

ERROR: Error during SonarScanner execution
java.lang.IllegalStateException: Line 192 is out of range in the file src/application/tracing/trace.rs (lines: 191)
    at org.sonar.api.utils.Preconditions.checkState(Preconditions.java:61)
    at org.sonar.api.batch.sensor.coverage.internal.DefaultCoverage.validateLine(DefaultCoverage.java:81)
    at org.sonar.api.batch.sensor.coverage.internal.DefaultCoverage.lineHits(DefaultCoverage.java:69)
    at org.elegoff.plugins.communityrust.coverage.cobertura.CoberturaParser.readFileContent(CoberturaParser.java:125)
    at org.elegoff.plugins.communityrust.coverage.cobertura.CoberturaParser.getFileMeasures(CoberturaParser.java:114)
    at org.elegoff.plugins.communityrust.coverage.cobertura.CoberturaParser.lambda$importReport$0(CoberturaParser.java:75)
    at org.elegoff.plugins.communityrust.coverage.cobertura.StaxParser.parse(StaxParser.java:69)
    at org.elegoff.plugins.communityrust.coverage.cobertura.StaxParser.parse(StaxParser.java:61)
    at org.elegoff.plugins.communityrust.coverage.cobertura.CoberturaParser.importReport(CoberturaParser.java:79)
    at org.elegoff.plugins.communityrust.coverage.cobertura.CoberturaSensor.importReport(CoberturaSensor.java:89)
    at org.elegoff.plugins.communityrust.coverage.cobertura.CoberturaSensor.execute(CoberturaSensor.java:62)
    at org.sonar.scanner.sensor.AbstractSensorWrapper.analyse(AbstractSensorWrapper.java:64)
    at org.sonar.scanner.sensor.ModuleSensorsExecutor.execute(ModuleSensorsExecutor.java:85)
    at org.sonar.scanner.sensor.ModuleSensorsExecutor.lambda$execute$1(ModuleSensorsExecutor.java:59)
    at org.sonar.scanner.sensor.ModuleSensorsExecutor.withModuleStrategy(ModuleSensorsExecutor.java:77)
    at org.sonar.scanner.sensor.ModuleSensorsExecutor.execute(ModuleSensorsExecutor.java:59)
    at org.sonar.scanner.scan.ModuleScanContainer.doAfterStart(ModuleScanContainer.java:79)
    at org.sonar.core.platform.ComponentContainer.startComponents(ComponentContainer.java:137)
    at org.sonar.core.platform.ComponentContainer.execute(ComponentContainer.java:123)
    at org.sonar.scanner.scan.ProjectScanContainer.scan(ProjectScanContainer.java:384)
    at org.sonar.scanner.scan.ProjectScanContainer.scanRecursively(ProjectScanContainer.java:380)
    at org.sonar.scanner.scan.ProjectScanContainer.doAfterStart(ProjectScanContainer.java:349)
    at org.sonar.core.platform.ComponentContainer.startComponents(ComponentContainer.java:137)
    at org.sonar.core.platform.ComponentContainer.execute(ComponentContainer.java:123)
    at org.sonar.scanner.bootstrap.GlobalContainer.doAfterStart(GlobalContainer.java:136)
    at org.sonar.core.platform.ComponentContainer.startComponents(ComponentContainer.java:137)
    at org.sonar.core.platform.ComponentContainer.execute(ComponentContainer.java:123)
    at org.sonar.batch.bootstrapper.Batch.doExecute(Batch.java:72)
    at org.sonar.batch.bootstrapper.Batch.execute(Batch.java:66)
    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(NativeMethodAccessorImpl.java:62)
    at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.base/java.lang.reflect.Method.invoke(Method.java:566)
    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:189)
    at org.sonarsource.scanner.api.EmbeddedScanner.execute(EmbeddedScanner.java:138)
    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)

Maybe not an issue, but I wanted to be sure if it was a correct behavior or not.

jaudiger commented 2 years ago

I analyzed the Cobertura report generated by grcov, and there was a line 192, and the number of lines in the file is 191... Don't know really why, but this issue comes from a bad report I guess...

Extract:

                        <line number="186" hits="0">
                        </line>
                        <line number="187" hits="0">
                        </line>
                        <line number="188" hits="0">
                        </line>
                        <line number="189" hits="0">
                        </line>
                        <line number="191" hits="0">
                        </line>
                        <line number="192" hits="0">

Maybe the analyzer should just ignore the unknown lines.

elegoff commented 2 years ago

Yes the coverage report contains file paths and Line numbers that SonarQube will try to reconcile with the source file it has scanned from the local folder.

It basically implies that the coverage report should be re-generated right before the SonarQube to be in full sync with the current state of the code base.

It is a commonly overlooked but is listed in the SonarQube docs as item 1 in https://docs.sonarqube.org/latest/analysis/coverage/#header-1

jaudiger commented 2 years ago

Well, I have no problem with lcov output coverage. In fact, I'm using this output format for a few months now. I just tried this afternoon with cobertura output and got this issue. For now, I switched back to lcov output with grcov.

elegoff commented 2 years ago

I did some local tests and could not reproduce unless the Cobertura report is out of sync, i.e the following sequence is applied :

generate the Cobertura coverage report
edit one of the covered file listed in the report , and remove some of the previously covered lines
Analyse on SonarQube with the now outdated report => you get the line out of range

As this is behaviour is expected for any language analyser , not specifically for this Rust plugin, I will close the issue for now. I may reconsider of course if more similar issues are faced for other users

jaudiger commented 2 years ago

If there is a way to obtain more logs to maybe help debug this issue, let me know.

elegoff commented 2 years ago

appending -X to the sonar-scanner command line provides verbose output.

I should also mentioned that the scenario should be

generate the Cobertura coverage report
Analyse on SonarQube without any file edition or SCM branch branch in the mean time

Indeed files editing after report is generated or analyzing on a different branch than the one used for the Coverage report generation is likely to cause mismatch on line numbers.

In other words when a coverage report refers to a line that no longer exists , the analysis is always expected to fail. The responsibility is on the coverage generation task (before involving the Sonar analysis) to provide something consistent with the state of the current source code.

I hope this clarifies

C4tWithShell / community-rust

Possible exception during analysis #44