SonarQube analysis failing due to exception in sensor.coverage.CoverageExclusions.validateMaxLine()

1,781 views
Skip to first unread message

Peter

unread,
Jan 26, 2016, 11:30:18 AM1/26/16
to SonarQube
Hi SonarQube-Team,

I'm a bit lost with an issue that started occurring recently in our analyses. I'd appreciate any hints!

Our system:
  • SonarQube Server 5.3
  • c# plugin 4.4
  • Git source code repository
  • SonarQube Scanner for MSBuild 1.1
  • Code coverage using OpenCover
After upgrading to SonarQube 5.3 and using the MSBuild Scanner, we are facing c# code analysis failures like this one:

ERROR: Error during Sonar runner execution
org
.sonar.runner.impl.RunnerException: Unable to execute Sonar
    at org
.sonar.runner.impl.BatchLauncher$1.delegateExecution(BatchLauncher.java:91)
    at org
.sonar.runner.impl.BatchLauncher$1.run(BatchLauncher.java:75)
    at java
.security.AccessController.doPrivileged(Native Method)
    at org
.sonar.runner.impl.BatchLauncher.doExecute(BatchLauncher.java:69)
    at org
.sonar.runner.impl.BatchLauncher.execute(BatchLauncher.java:50)
    at org
.sonar.runner.api.EmbeddedRunner.doExecute(EmbeddedRunner.java:102)
    at org
.sonar.runner.api.Runner.execute(Runner.java:100)
    at org
.sonar.runner.Main.executeTask(Main.java:70)
    at org
.sonar.runner.Main.execute(Main.java:59)
    at org
.sonar.runner.Main.main(Main.java:53)
Caused by: java.lang.IllegalStateException: Can't create measure for line 38 for file 'XY' with 37 lines
    at org.sonar.batch.
sensor.coverage.CoverageExclusions.validateMaxLine(CoverageExclusions.java:158)
    at org.sonar.batch.sensor.coverage.CoverageExclusions.validate(CoverageExclusions.java:129)
    at org.sonar.batch.deprecated.DeprecatedSensorContext.saveMeasure(DeprecatedSensorContext.java:204)
    at org.sonar.plugins.dotnet.tests.CoverageReportImportSensor.analyze(CoverageReportImportSensor.java:78)


This is an excerpt of the part inside our code coverage report that seems to be causing the failure. Notice the attributes "fileid" changing inside that listing of sequence points.
        <Method someattributes>
             
<Summary SOMESUMMARY/>
             
<MetadataToken>100664043</MetadataToken>
             
<Name>System.Void SOMEMETHOD::.ctor()</Name>
             
<FileRef uid="11618" />
             
<SequencePoints>
               
<SequencePoint vc="1" uspid="902191" ordinal="0" offset="0" sl="8" sc="9" el="8" ec="68" bec="0" bev="0" fileid="11618" />
               
<SequencePoint vc="1" uspid="902192" ordinal="1" offset="7" sl="32" sc="15" el="32" ec="76" bec="0" bev="0" fileid="11619" />
               
<SequencePoint vc="1" uspid="902193" ordinal="2" offset="17" sl="33" sc="9" el="33" ec="10" bec="0" bev="0" fileid="11619" />
               
<SequencePoint vc="1" uspid="902194" ordinal="3" offset="18" sl="34" sc="13" el="34" ec="35" bec="0" bev="0" fileid="11619" />
               
<SequencePoint vc="1" uspid="902195" ordinal="4" offset="25" sl="35" sc="13" el="35" ec="106" bec="0" bev="0" fileid="11619" />
               
<SequencePoint vc="1" uspid="902196" ordinal="5" offset="48" sl="37" sc="13" el="37" ec="128" bec="0" bev="0" fileid="11619" />
               
<SequencePoint vc="1" uspid="902197" ordinal="6" offset="76" sl="38" sc="13" el="38" ec="149" bec="0" bev="0" fileid="11619" />
               
<SequencePoint vc="1" uspid="902198" ordinal="7" offset="104" sl="39" sc="9" el="39" ec="10" bec="0" bev="0" fileid="11619" />
             
</SequencePoints>
             
<BranchPoints />
             
<MethodPoint xsi:type="SequencePoint" vc="1" uspid="902191" ordinal="0" offset="0" sl="8" sc="9" el="8" ec="68" bec="0" bev="0" fileid="11618" />
       
</Method>

The method being analysed here is the constructor of a partial class in file with fileid="11619" inheriting from a partial class in another file with fileid="11618"
So, the sequence actually calls into another file. OpenCover seems to resolve this properly (as you can see by the changing fileids in the sequence listing)

The failure described above now occurs only for those situations where the file being called has fewer lines than the file the sequence started in.
In the case shown above, the starting file (11619) has some 200 lines whereas the file being called (11618) has 37 lines only. Parsing of the coverage report works fine until the line with sl="38" is reached.

If I manually remove these calls or if I manually change the "FileRef" parameter to the larger file, the analysis works just fine.
In defense of OpenCover: If I parse that report with ReportGenerator, for example, the report is parsed fine and coverage information on those parts of the code seems reasonable as well.

So my hypothesis is that there is something wrong with the way the "org.sonar.batch.sensor.coverage.CoverageExclusions.validateMaxLine" is calculated.
Maybe it does not take into account the fact that there are multiple files with a different number of lines involved?

Well, I hope this is helpful to you. I would really appreciate any inputs you could give me.
Thanks!

jakub...@adspired.com

unread,
Jan 27, 2016, 7:00:50 AM1/27/16
to SonarQube, p.ni...@gmail.com
I see the same type of error since upgrading to 5.3. 
Using cobertura to generate coverage.xml.

codexa...@gmail.com

unread,
Jan 27, 2016, 2:17:52 PM1/27/16
to SonarQube, p.ni...@gmail.com
Getting the same issue here. Identical setup.
...

marko...@gmail.com

unread,
Feb 10, 2016, 8:00:58 AM2/10/16
to SonarQube, p.ni...@gmail.com

We also hit this issue. I was able to track it down to sonar-dotnet-tests-library, class OpenCoverReportParser, method handleSegmentPointTag. Adding usage of fileid if present resolved the issue for us:

----- fixed method starts ----

private void handleSegmentPointTag() {
  int line = xmlParserHelper.getRequiredIntAttribute("sl");
  int vc = xmlParserHelper.getRequiredIntAttribute("vc");
  String fileId = xmlParserHelper.getAttribute("fileid");
  if (fileId == null || fileId.trim() == ""){
    fileId = fileRef;
  }

  if (files.containsKey(fileId)) {
    coverage.addHits(files.get(fileId), line, vc);
  }
}

----- fixed method ends ----

With this change I was able to build a version of c# plugin that utilized the fixed library and now my partial class analyses are working again. Please open a JIRA issue to track the official fix.

Cheers,
Marko
...

Dinesh Bolkensteyn

unread,
Mar 14, 2016, 8:21:05 AM3/14/16
to SonarQube, p.ni...@gmail.com
Thanks, I've just created the following ticket: https://jira.sonarsource.com/browse/SONARNTEST-31

@Marko - Feel free to submit a PR of your changes if you still have them around


On Tuesday, January 26, 2016 at 5:30:18 PM UTC+1, Peter wrote:

Marko Lahma

unread,
Mar 16, 2016, 2:38:57 AM3/16/16
to Dinesh Bolkensteyn, SonarQube, p.nill81
I've created PR based on the change we had to make:

https://github.com/SonarSource/sonar-dotnet-tests-library/pull/22


> Thanks, I've just created the following ticket: https://jira.sonarsource.com/browse/SONARNTEST-31 @Marko - Feel free to submit a PR of your changes if you still have them around On Tuesday, January 26, 2016 at 5:30:18 PM UTC+1, Peter wrote: Hi SonarQube-Team, I'm a bit lost with an issue that started occurring recently in our analyses. I'd appreciate any hints! Our system: SonarQube Server 5.3c# plugin 4.4Git source code repositorySonarQube Scanner for MSBuild 1.1Code coverage using OpenCover After upgrading to SonarQube 5.3 and using the MSBuild Scanner, we are facing c# code analysis failures like this one: ERROR: Error during Sonar runner execution org.sonar.runner.impl.RunnerException: Unable to execute Sonar at org.sonar.runner.impl.BatchLauncher$1.delegateExecution(BatchLauncher.java:91) at org.sonar.runner.impl.BatchLauncher$1.run(BatchLauncher.java:75) at java.security.AccessController.doPrivileged(Native Method) at org.sonar.runner.impl.BatchLauncher.doExecute(BatchLauncher.java:69) at org.sonar.runner.impl.BatchLauncher.execute(BatchLauncher.java:50) at org.sonar.runner.api.EmbeddedRunner.doExecute(EmbeddedRunner.java:102) at org.sonar.runner.api.Runner.execute(Runner.java:100) at org.sonar.runner.Main.executeTask(Main.java:70) at org.sonar.runner.Main.execute(Main.java:59) at org.sonar.runner.Main.main(Main.java:53) Caused by: java.lang.IllegalStateException: Can't create measure for line 38 for file 'XY' with 37 lines at org.sonar.batch.sensor.coverage.CoverageExclusions.validateMaxLine(CoverageExclusions.java:158) at org.sonar.batch.sensor.coverage.CoverageExclusions.validate(CoverageExclusions.java:129) at org.sonar.batch.deprecated.DeprecatedSensorContext.saveMeasure(DeprecatedSensorContext.java:204) at org.sonar.plugins.dotnet.tests.CoverageReportImportSensor.analyze(CoverageReportImportSensor.java:78) This is an excerpt of the part inside our code coverage report that seems to be causing the failure. Notice the attributes "fileid" changing inside that listing of sequence points. <summary> 100664043 System.Void SOMEMETHOD::.ctor() The method being analysed here is the constructor of a partial class in file with fileid="11619" inheriting from a partial class in another file with fileid="11618" So, the sequence actually calls into another file. OpenCover seems to resolve this properly (as you can see by the changing fileids in the sequence listing) The failure described above now occurs only for those situations where the file being called has fewer lines than the file the sequence started in. In the case shown above, the starting file (11619) has some 200 lines whereas the file being called (11618) has 37 lines only. Parsing of the coverage report works fine until the line with sl="38" is reached. If I manually remove these calls or if I manually change the "FileRef" parameter to the larger file, the analysis works just fine. In defense of OpenCover: If I parse that report with ReportGenerator, for example, the report is parsed fine and coverage information on those parts of the code seems reasonable as well. So my hypothesis is that there is something wrong with the way the "org.sonar.batch.sensor.coverage.CoverageExclusions.validateMaxLine" is calculated. Maybe it does not take into account the fact that there are multiple files with a different number of lines involved? Well, I hope this is helpful to you. I would really appreciate any inputs you could give me. Thanks!</summary>

sar...@gmail.com

unread,
Mar 26, 2016, 12:11:08 PM3/26/16
to SonarQube, dinesh.bo...@sonarsource.com, p.ni...@gmail.com, marko...@gmail.com
Hi All,

I am new to SonarQube. With "SonarQube Server 5.3" and "c# plugin 4.4" am also facing this issue and noticed that this issue has been resolved. https://jira.sonarsource.com/browse/SONARNTEST-31

Has it been released? Could someone tell me how to get this update? 

Thanks for your help.

thanks
Saran

nikita...@gmail.com

unread,
Mar 28, 2016, 10:05:40 AM3/28/16
to SonarQube, dinesh.bo...@sonarsource.com, p.ni...@gmail.com, marko...@gmail.com, sar...@gmail.com
C# Plugin 5.1 include this change



суббота, 26 марта 2016 г., 19:11:08 UTC+3 пользователь sar...@gmail.com написал:

Saravanakumar M

unread,
Mar 28, 2016, 11:00:43 AM3/28/16
to nikita...@gmail.com, SonarQube, dinesh.bo...@sonarsource.com, p.ni...@gmail.com, marko...@gmail.com
Thanks for your reply.

I really appreciate it.

-Saravana

Saravanakumar M

unread,
Mar 28, 2016, 11:05:43 AM3/28/16
to nikita...@gmail.com, SonarQube, dinesh.bo...@sonarsource.com, p.ni...@gmail.com, marko...@gmail.com
Hi,

Is there any way I can get the C# plugin 5.1 now to test it? 
I would like to get my setup going in the meantime.

thanks for your help.

-Saravana


On Mon, Mar 28, 2016 at 7:05 AM, <nikita...@gmail.com> wrote:

xti...@gmail.com

unread,
Oct 4, 2016, 7:22:43 PM10/4/16
to SonarQube, p.ni...@gmail.com
Still happening in SonarQube 5.6 using the C# 5.3.2
Reply all
Reply to author
Forward
0 new messages