VisualStudioCoverageSensor line is out of range

Report a bug
#1

We have a similar issue with sonar.cfamily.vscoveragexml.reportsPath. I tested it with sonar-cfamily-plugin-6.6.0.13759.jar at SonarQube Enterprise Edition version 8.1 (build 31237) without success.

java.lang.IllegalStateException: Line 190 is out of range in the file <PROJECT>/<SOURCE_FILE>.cpp (lines: 189)
	at org.sonar.api.utils.Preconditions.checkState(Preconditions.java:61)
	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 com.sonar.cpp.plugin.visualstudio.VisualStudioCoverageSensor.execute(VisualStudioCoverageSensor.java:76)
	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.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: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:386)
	at org.sonar.scanner.scan.ProjectScanContainer.scanRecursively(ProjectScanContainer.java:382)
	at org.sonar.scanner.scan.ProjectScanContainer.scanRecursively(ProjectScanContainer.java:379)
	at org.sonar.scanner.scan.ProjectScanContainer.doAfterStart(ProjectScanContainer.java:351)
	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:141)
	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: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:567)
	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:112)
	at org.sonarsource.scanner.cli.Main.execute(Main.java:75)
	at org.sonarsource.scanner.cli.Main.main(Main.java:61)
SonarQube Scanner crashing when parsing gcov reports: Line is out of range
#2

Hi @HofmeisterAn,

would you be able to share the entire sonar-scanner output log and the visual studio coverage report?
I can send you a PM where you can share privately.

#3

@mpaladin Of course, a PM would be nice - thanks. I noticed that the file only has 189 lines instead of 190. I have this issue with a couple of files. Sonar always complains about a length +1.

#4

For the records it seems that the generated xml report was containing invalid lines and so the sensor was failing because of invalid lines.

Everything seems to be good on the analyzer side, the issue comes from the report generation which is not under our control, we can consider this topic as closed.

#5

I ran into this same issue. Looking into the coverage XML file I was able to see that a function was being added by the pre-compiler (__empty_global_delete) at the end of the source file. I just had to add an exclusion filter to my test settings and problem solved.

#6

Hi @Sean_Jost,

thank you for your information, would you be able to provide a small reproducer to show what happens?

#7

@Sean_Jost Can you explain how you fixed your issue? We still face it. At some places we noticed that removing C++ 14 language features “fix” it, but that’s only a workaround. We also notice that it behaves different with certain runsettings. Did you change your runsetting like DynamicCoverageDataCollector?

#8

Hi @HofmeisterAn,

if it happens only on test files you may want to just exclude them from the analysis.

I am not sure to whom you are addressing this question.

#9

Hi @mpaladin,

It happens on our source files, a lot of them. Until now, we’re not able to analyze C++ projects at all. At least with code coverage enabled. Which is disappointing.

This was addressed to @Sean_Jost. Maybe he can explain a little bit more what he excluded.

I attached our findings below. Maybe they will help one or the other:

  1. We noticed that each broken source file contains a function that is covered by two source files (.h; .cpp). All other functions are covered by a single file.

  2. We noticed different behaviors as soon as we exclude <Source>.*\\vc\\tools\\msvc\\.*</Source>, a bunch of errors are gone, but still too many left. Notice that in previous versions of Visual Studio those files were excluded by <Source>.*\\vctools\\.*</Source> which is the default configuration by Microsoft. In the latest versions of Visual Studio, Microsoft moved them to vc\tools\msvc\.

  3. Even only including our own namespace in the code coverage analysis won’t work. We still get the line is out of range exception.

  4. Removing C++ 14 language features fixed some issues.

  5. <SupportJustMyCode>false</SupportJustMyCode> fixed some issues, see 411331@Developer Community.

#10

Hi @HofmeisterAn,

thank you for the link, I am going to give a look, it may help to understand a bit better the situation. If you provide us a minimal project reproducing the issue it would be easier for us. Given the situation we may evaluate to ignore reports related to unexisting line numbers.

#12

Hi @HofmeisterAn,

I created a ticket to track the issue: CPP-2879. We are going to ignore entries on exceeding line numbers, it is going to be released in the next version.