Sonarqube scan error with line out of range?

Question

[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.

Tollbooth

Which version of SonarQube and of Java Plugin are you using ? what is the encoding of File.java on which this is failing ? – Tifanytiff

Hello, Having the same issue with SonarQube 5.6.2, java plugin 4.2, file encoded in utf-8 – Preachment

It seemed to just start working the day after I posted this.... No changes made – Tollbooth

Having the same issue here. Using Maven on a groovy project with SonarQube 6.1. – Glamorous

I had the same issue and I resolved it by copy & pasting the entire contents of the offending class into TextWrangler, then copy & pasting it back into Visual Studio. It sounds silly, but I switch back & forth between developing on PC and Mac and I guess I normalized the line breaks at some point, which may have caused an issue. – Alum

Answer 1

I had the same issue when using sonar maven plugin and jacoco test reports. mvn sonar:sonar relies on an existintig jacoco report, when the source code was changed (lines had been removed), but the test report wasn't updated this error occurred. Running mvn clean test sonar:sonar solved it.

Proulx

True. I got the same problem and the cause was also an outdated jacoco report. – Pistachio

Answer 2

I tried gradle clean buildand it worked for me

Grapery

This does not provide an answer to the question. Once you have sufficient reputation you will be able to comment on any post; instead, provide answers that don't require clarification from the asker. - From Review – Store

@PankajMakwana Disagree. Just because it is short it does not mean it is not an answer. I see this as answer and not a comment. – Nessy

Answer 3

Same damn issue happens in python code as well. I got it resolved adding a blank line at the end of the file.

Folly

For me it was the coverage xml that wasn't refreshing with deleted files. – Aubree

Answer 4

For me it was because I had exactly the same class (for example com.test.MyClass) name and package name in two different sub modules (maven), MyClass in first module is larger i.e. 120 lines of code. MyClass in second module is shorter, then the exception was thrown since JaCoCo though the report was for that.

Solution was to rename one of the classes or move it into a different package.

i.e. : com.test.MyClass and com.test.MyClassB

OR:

com.test.MyClass and com.test.foo.MyClass

Unifoliolate

Answer 5

For Azure DevOps, you might want to make sure your build cleans sources before it starts building.

Desalvo

Answer 6

We had the same problem on our AspNET-Core-Project.

We then saw, that we had testfailures that unfortunately didn't cause our Jenkins-Job to fail. Instead sonarqube analyzing the tests and coverage produced the error.

Once the tests were fixed everything worked well again.

Mindy

Answer 7

I encountered the same problem, and after researching a lot, I found out that the Tests were not being built (so they are not reflecting the latest source code).

1st fix: when calling msbuild.exe I was just using msbuild.exe /t:Rebuild, now I'm using msbuild.exe /t:Clean;Rebuild so I can see that no tests were being built anymore.

2nd fix: I was ignoring the errors from TypeScript. So by running msbuild.exe isolated, I was able to see that TypeScript errors were breaking the msbuild execution before the tests can be built. Tip: don't ignore any errors and try to run the commands outside the script.

✔ This way a fresh test DLL will be built, and when coverage compares the methods/classes it will match the right source code file. 😀

Meghannmegiddo

Answer 8

If executing a maven clean does not work check if you have any old project folder that needs to be cleaned. Once you remove a submodule from the maven pom it won't remove the folder including the /target directory with the jacoco report from ages ago.

Gerome

Answer 9

In my case, an iOS project written in Swift had to remove previous reports. Just delete sonar-reports folder.

Superannuation

Answer 10

I got the very same error with Azure DevOps Pipelines, but a cleanup before building the solution for sources and output did the job.

Now everything is working fine again.

Heeling

How do you do this? I have this issue as part of an Azure DevOps pipeline. – Steinway

Answer 11

Major reasons for this problem:-

1. Yes this issue arises when there is a recent change in the repository but you are not using the updated image in the yaml file and this error will always be seen in the latest committed file in the repo.

for ex - docker run -dt --name ${{variables.containerName}} ${{variables.tempimage}} /bin/bash

2. In the above command we are invoking the containerName and then using some tempimage so if this tempimage is updated(means pointing to the latest repo) then only you will be able to resolve this issue if we have a mismatch in the repo at sonarqube and in the yaml file then we will get this issue.

3. To get the latest image we can use Team_image_builder inside the yaml file and if we remove the latest committed file from the repo then this issue will not come because difference of both sides would be zero then.

Marion

Answer 12

Delete the coverage reports from the previous run before running again.

Physiognomy

Answer 13

To avoid issues with the coverage report, make sure to delete it before executing it again. First, build your xml file and then execute sonar-scanner. To do this, run the following commands in sequence: coverage xml, coverage html, and sonar-scanner. Alternatively, you can try removing the .coverage and .scannerwork files.

Lynnette