Sonarqube scan error with line out of range?

[ronan....@gmail.com]

[07:43:57]W: [Step 1/1] ERROR: Error during SonarQube Scanner execution


[07:43:57]W: [Step 1/1] ERROR: Line 523 is out of range in the file src/main/java/com/company/package/File.java (lines: 522)

For some reason Sonarqube is reporting an error on line 523 but there is only 522 lines in the source file ?

I saw this on a previous file, but when I added a blank line to the end of it the problem went away, this file already has a blank line at the end of it.

[G. Ann Campbell]

Hi,

First, the standard courtesies ("Hi", "Thanks", &etc) are appreciated in this group.

Second, please do not cross-post here and on StackOverflow. Both channels are monitored on an "at best" basis, and you've just used twice your share of bandwidth.

Ann

[rveera...@gmail.com]

Hi Ann,

   Sorry to bother you. I noticed that there has no more activities on this subject. We too have been getting similar error messages at times. For us, the workaround has been (though it sounds arbitrary) was to add a comment at the end of the file. Since we have 100's of projects and with CI/CD it has become quite hard to 'fix' this issue. So, my question is, what can I do? Should i look forward to a fix in the next release? Please help!

Thanks,

   Ravi

[Nicolas Peru]

Hi, 

Which version of SonarQube and the sonar java analyzer are you using ? 

Cheers, 

--
You received this message because you are subscribed to the Google Groups "SonarQube" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sonarqube+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sonarqube/164f32b6-66b8-41d0-8a68-a390937c4d89%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Nicolas PERU | SonarSource

Senior Developer
http://sonarsource.com

https://twitter.com/benzonico

[Deven Phillips]

I am having a similar issue:

SonarQube: 6.1

Groovy Plugin: 1.4

Maven/Groovy project

[ERROR] Failed to execute goal org.sonarsource.scanner.maven:sonar-maven-plugin:3.0.2:sonar (default-cli) on project REDACTED: Line 92 is out of range in the file src/main/groovy/REDACTED/Status.groovy (lines: 91) -> [Help 1]

Status.groovy is only 90 lines long...

Here's my sonar properties from the Maven pom:

    <properties>
        <maven.compiler.source>1.8</maven.compiler.source>
        <maven.compiler.target>1.8</maven.compiler.target>
        <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
        <sonar.language>grvy</sonar.language>
        <sonar.sources>src</sonar.sources>
        <sonar.tests></sonar.tests>
        <sonar.dynamicAnalysis>reuseReports</sonar.dynamicAnalysis>
        <sonar.java.coveragePlugin>jacoco</sonar.java.coveragePlugin>
        <sonar.jacoco.reportPath>build/test-reports/jacoco.exec</sonar.jacoco.reportPath>
    </properties>

Any assistance would be GREATLY appreciated...

Deven Phillips

[Deven Phillips]

Doh! OK, my bad... Removing sonar.sources and sonar.tests from the maven properties fixed the issue 'Line 92 is out of range in the file src/main/groovy/REDACTED/Status.groovy'

Deven

[R Veeraraghavan]

Hi Nicolas, 

  Thanks a lot for the explanation. I realize it is aspectJ, jacoco clash which is creating the issue. I also read I can change the instrumentation order. I am not sure how I can achieve that. Can you point me in the right direction so I will be able to change the sonarqube code coverage analysis order and do jacoco code coverage before aspectJ code coverage? ( or turn off aspectJ all together if possible )

Thanks,

    Ravi

[R Veeraraghavan]

Hi Nicolas,

    After looking to see how we could possibly have this issue fixed with minimum disruption ( rewriting the Tests in isolation etc is just too time consuming at this time ) the one 'solution' I am thinking of is the following. Per the stack trace I get ( I have copied it above in one of my replies ), this is what I did.

In the plugin sonar-java, there is a file AbstractAnalyzer.java under the package org.sonar.plugins.jacoco. In that file there is this method analyzeFile,  that method makes a call to lineHits on the object NewCoverage and another method later down conditions. Now, there is nothing wrong with these calls or anything wrong with the method itself, but the problem is the coordination of line numbers coming from ISourceFileCoverage and the actual file. The object ISourceFileCoverage itself is created a bit earlier with calls to jacoco which calls asm package - I don't have enough info in the actual analysis, but again I could not see anything wrong anywhere over there. Individually the functionalities seem fine, but the calls result in exceptions as the line numbers simply don't match. 

So, my simple solution was to add a try/catch and just log it and continue - this 'fixes' the issue and all our projects finish.

So, my question is, what do you think of this 'fix'? And if you think it makes sense, should I think of adding a config option which will be used to ignore this error ( when this option is on, it will do a try/catch and log the error and when the option is off, it will behave the way it does today which is to throw an exception. What do you think?

Thanks,

   Ravi

[Nicolas Peru]

Hi, 

This is not a fix, this is just hiding the problem under the rug. The real issue is how aspectJ is interacting with JaCoCo prior to any reading of the coverage report and this is where things should be fixed rather than modifying SonarJava code. 

Cheers, 

--
You received this message because you are subscribed to the Google Groups "SonarQube" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sonarqube+...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/sonarqube/CAEAb9wN6uB0Uv2ArT2e55x%3DwiS81_g9emqHcvo0N1VowafLzYA%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

[philip...@gmail.com]

Hi Nicolas,

I also see this error with Java and Jacoco without using aspectJ so I don't believe that the problem lies with aspectJ and Jacoco.

In my case, line 294 is reported on a Java file that only has 254 lines. I checked the Jacoco report and there it also says that the file in question has 254 lines.

Using the verbose option when executing Ant, I noticed that this particular class generated the following message:

[sonar:sonar] The class 'classNameHere' could not be match to its original source file. It might be a dynamically generated class.

And in my case, it is not a generated class. May be this is a hint?

I am using:

• Sonarqube 6.1 (it also happens with 6.2)
  
• Java plug-in 4.3.0.7717
  
• Jacoco 0.7.7.201606060606
  
• Sonarqube ant task 2.5
  

Philippe

[Nicolas Peru]

Hi philippe, 

Can you please share the log of the analysis ? so we can be sure that the problem is due to JaCoCo reporting (and not happening at another stage of the analysis). 

if we assume it is happening during report analysis : Do you have any tool weaving bytecode (besides AspectJ) ? 

Cheers, 

--

You received this message because you are subscribed to the Google Groups "SonarQube" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sonarqube+...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/sonarqube/8de31aa8-2b06-4bab-b128-81bc851d3d3e%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[R Veeraraghavan]

Hi Nicolas,

   Our initial issues centered around code which had AOP, but, like Philippe, I too have examples where we get similar line number issue when running sonarqube on java code which are pojos. These are very simple java classes. However and unlike aspectJ issue, here is what happens in these cases. if we use gradle clean ( followed by sonar tasks ) - then the error goes away. Alternatively, running a failed build a second time ( forcing a clean ), makes the error go away. Strange but yes, that has been our workaround for all except the AOP case.

Does this help in any way?

Thanks,

   Ravi

On Tue, Jan 10, 2017 at 5:09 AM, Nicolas Peru <nicola...@sonarsource.com> wrote:

Hi philippe, 

Can you please share the log of the analysis ? so we can be sure that the problem is due to JaCoCo reporting (and not happening at another stage of the analysis). 

if we assume it is happening during report analysis : Do you have any tool weaving bytecode (besides AspectJ) ? 

Cheers, 

Le ven. 30 déc. 2016 à 14:32, <philip...@gmail.com> a écrit :

Hi Nicolas,

I also see this error with Java and Jacoco without using aspectJ so I don't believe that the problem lies with aspectJ and Jacoco.

In my case, line 294 is reported on a Java file that only has 254 lines. I checked the Jacoco report and there it also says that the file in question has 254 lines.

Using the verbose option when executing Ant, I noticed that this particular class generated the following message:

[sonar:sonar] The class 'classNameHere' could not be match to its original source file. It might be a dynamically generated class.

And in my case, it is not a generated class. May be this is a hint?

I am using:

• Sonarqube 6.1 (it also happens with 6.2)
  
• Java plug-in 4.3.0.7717
  
• Jacoco 0.7.7.201606060606
  
• Sonarqube ant task 2.5
  

Philippe

--

You received this message because you are subscribed to the Google Groups "SonarQube" group.

To unsubscribe from this group and stop receiving emails from it, send an email to sonarqube+unsubscribe@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/sonarqube/8de31aa8-2b06-4bab-b128-81bc851d3d3e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Nicolas PERU | SonarSource

Senior Developer
http://sonarsource.com

https://twitter.com/benzonico

--
You received this message because you are subscribed to a topic in the Google Groups "SonarQube" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/sonarqube/F_DNgeew0Sw/unsubscribe.
To unsubscribe from this group and all its topics, send an email to sonarqube+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sonarqube/CAFHtbL3J3KZbc0-5B640PY0OVvOAMgLc7hFr1wU04xY4QtVUnw%40mail.gmail.com.

[Nicolas Peru]

[Making this answer public] 

Hi Phillipe, 

I just happen to notice that you are using findbugs. Would it be possible to deactivate all the findbugs rules and/or deinstall the findbugs plugin and rerun the analysis ? 

This test would allow to know if the problem lies in the SonarJava Analyzer OR findbugs which we don't know for sure at the moment.

Thanks

Le ven. 30 déc. 2016 à 14:32, <philip...@gmail.com> a écrit :

--

You received this message because you are subscribed to the Google Groups "SonarQube" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sonarqube+...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/sonarqube/8de31aa8-2b06-4bab-b128-81bc851d3d3e%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[philip...@gmail.com]

Hi Nicolas,

I uninstalled the FindBugs plug-in and ran the analysis again, the out of range still happens. This time on a different file. The code being analyzed has however changed between both analysis.

Philippe

[toni...@gmail.com]

Hi Philippe, Nicolas and All

I have the same issue in my SONAR.

I am using jacoco on-the-fly instrumentation, and expected to have code coverage report on SONAR without re-build the source code.

Do you have any idea to solve the issue?

Thank you.

Regards,

Toni

philip...@gmail.com於 2017年1月12日星期四 UTC上午11時45分50秒寫道：

[G. Ann Campbell]

Hi Toni,

Please don't excavate old threads. Instead start a new thread & supply your versions.

Ann