Kotlin class coverage information fails importing due to Line 65535 is out of range in the file

vicsonvictor · May 2, 2022, 4:42pm

Version used: sonar-scanner-cli-4.7.0.2747
Trying to achieve: Get coverage report generated using jacoco uploaded to sonar cloud using the sonarqube CLI without these out of range errors.
Things tried so far: Using the latest version of sonar and 0.8.8 version of Jacoco and coverage reports are generated everytime we run our CI workflows, so its not stale.

We have approx 10 classes which fail with the same exception as below. The interesting part is all class import failures log with the same ‘Line 65535 is out of range…’ error. Notice the 65535 line number indicated. That sounds kind of fishy. Any clues on why we are seeing this on a handful of classes ?

ERROR: Cannot import coverage information for file 'uiToolkit/src/main/java/com/shiftkey/uiToolkit/common/ui/compose/Snackbar.kt', coverage data is invalid. Error: {}
java.lang.IllegalStateException: Line 65535 is out of range in the file uiToolkit/src/main/java/com/shiftkey/uiToolkit/common/ui/compose/Snackbar.kt (lines: 63)
	at org.sonar.api.utils.Preconditions.checkState(Preconditions.java:61)
	at org.sonar.api.batch.sensor.coverage.internal.DefaultCoverage.validateLine(DefaultCoverage.java:67)
	at org.sonar.api.batch.sensor.coverage.internal.DefaultCoverage.conditions(DefaultCoverage.java:81)
	at org.sonar.plugins.jacoco.ReportImporter.importCoverage(ReportImporter.java:41)
	at org.sonar.plugins.jacoco.JacocoSensor.importReport(JacocoSensor.java:79)
	at org.sonar.plugins.jacoco.JacocoSensor.importReports(JacocoSensor.java:62)
	at org.sonar.plugins.jacoco.JacocoSensor.execute(JacocoSensor.java:47)
	at org.sonar.scanner.sensor.AbstractSensorWrapper.analyse(AbstractSensorWrapper.java:62)
	at org.sonar.scanner.sensor.ModuleSensorsExecutor.execute(ModuleSensorsExecutor.java:75)
	at org.sonar.scanner.sensor.ModuleSensorsExecutor.lambda$execute$1(ModuleSensorsExecutor.java:48)
	at org.sonar.scanner.sensor.ModuleSensorsExecutor.withModuleStrategy(ModuleSensorsExecutor.java:66)
	at org.sonar.scanner.sensor.ModuleSensorsExecutor.execute(ModuleSensorsExecutor.java:48)
	at org.sonar.scanner.scan.ModuleScanContainer.doAfterStart(ModuleScanContainer.java:64)
	at org.sonar.core.platform.ComponentContainer.startComponents(ComponentContainer.java:123)
	at org.sonar.core.platform.ComponentContainer.execute(ComponentContainer.java:109)
	at org.sonar.scanner.scan.ProjectScanContainer.scan(ProjectScanContainer.java:440)
	at org.sonar.scanner.scan.ProjectScanContainer.scanRecursively(ProjectScanContainer.java:436)
	at org.sonar.scanner.scan.ProjectScanContainer.doAfterStart(ProjectScanContainer.java:394)
	at org.sonar.core.platform.ComponentContainer.startComponents(ComponentContainer.java:123)
	at org.sonar.core.platform.ComponentContainer.execute(ComponentContainer.java:109)
	at org.sonar.scanner.bootstrap.GlobalContainer.doAfterStart(GlobalContainer.java:128)
	at org.sonar.core.platform.ComponentContainer.startComponents(ComponentContainer.java:123)
	at org.sonar.core.platform.ComponentContainer.execute(ComponentContainer.java:109)
	at org.sonar.batch.bootstrapper.Batch.doExecute(Batch.java:58)
	at org.sonar.batch.bootstrapper.Batch.execute(Batch.java:52)
	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)

Thanks for the help.

Colin · May 3, 2022, 8:25am

Hey there.

That is a super fishy number.

If the XML coverage report is referencing a line 65535 (which you should be able to check) on a file that shouldn’t be that long (and for your sake I hope you aren’t working in files that large!), you probably want to raise an issue on GitHub - jacoco/jacoco: Java Code Coverage Library. SonarQube doesn’t generate coverage reports, it only reads them.

vicsonvictor · May 4, 2022, 7:33pm

@Colin You are correct, the classes which report this ridiculous numbers are present in the XML coverage report.

		<sourcefile name="DisableInteraction.kt">
			<line nr="15" mi="70" ci="0" mb="18" cb="0"/>
			<line nr="16" mi="2" ci="0" mb="2" cb="0"/>
			<line nr="17" mi="14" ci="0" mb="0" cb="0"/>
			<line nr="18" mi="2" ci="0" mb="0" cb="0"/>
			<line nr="19" mi="2" ci="0" mb="0" cb="0"/>
			<line nr="20" mi="4" ci="0" mb="0" cb="0"/>
			<line nr="21" mi="16" ci="0" mb="0" cb="0"/>
			<line nr="22" mi="16" ci="0" mb="0" cb="0"/>
			<line nr="25" mi="18" ci="0" mb="2" cb="0"/>
			<line nr="65535" mi="6" ci="0" mb="2" cb="0"/>
			<counter type="INSTRUCTION" missed="151" covered="0"/>
			<counter type="BRANCH" missed="24" covered="0"/>
			<counter type="LINE" missed="10" covered="0"/>
			<counter type="COMPLEXITY" missed="14" covered="0"/>
			<counter type="METHOD" missed="2" covered="0"/>
			<counter type="CLASS" missed="2" covered="0"/>
		</sourcefile>

This particular class has only 25 lines, so this line entry makes no sense:

<line nr="65535" mi="6" ci="0" mb="2" cb="0"/>

I will create an issue on the Jacoco Github repo.

vicsonvictor · May 4, 2022, 7:50pm

@Colin Does the sonar JacocoSensor use the jacoco library indirectly? Wondering if its a different version compared to the one used to generated the reports.

I found the following: Kotlin: Report shows incorrect number of lines · Issue #1190 · jacoco/jacoco · GitHub

And I have confirmed that our reports are generated with the most recent jacoco version(0.8.8)

Colin · May 6, 2022, 11:31am

Hey there.

SonarQube just parses the XML report – it doesn’t depend on the JaCoCo library.

johnmichelau-flock · February 9, 2023, 9:26pm

Did anyone ever resolve this? I’m seeing the same on Jacoco 0.8.8, and I’m also using Compose UI.

Margarita_Nedzelska · February 14, 2023, 9:33am

Hey @johnmichelau-flock,

Thanks for your message. If you read this thread carefully, you may notice that the reported problem is in the XML report generated by JaCoCo. Sonar just parses it. So the original problem should be reported and solved on the JaCoCo side.

And there was indeed a reported issue on their side:Kotlin: Report shows incorrect number of lines · Issue #1190 · jacoco/jacoco · GitHub

From the conversation, you can find out that the version specified in gradle build was not taken into consideration, and Gradle used the old version of JaCoCo: Kotlin: Report shows incorrect number of lines · Issue #1190 · jacoco/jacoco · GitHub
because of
Jacoco HTML report displays wrong "created with" version · Issue #14033 · gradle/gradle · GitHub

So, if you have a proper reproducer, please, report the issue in the right place: jacoco or Gradle. In Sonar we just parse the report, and the line was already incorrect in the report.

Regards,
Margarita