Recently, I was having some bother trying to use Sonar 5.1 with my Grails 2.4.4 project. I was using the usual Groovy stuff:Gmetrics, Codenarc and Cobertura. For the Sonar database I was using Postgres 9.4.
The logfile for the Sonar runner just gave me this:
build 22-Jun-2015 07:44:30 INFO: ------------------------------------------------------------------------ build 22-Jun-2015 07:44:30 INFO: EXECUTION FAILURE build 22-Jun-2015 07:44:30 INFO: ------------------------------------------------------------------------ build 22-Jun-2015 07:44:30 Total time: 9.153s build 22-Jun-2015 07:44:30 Final Memory: 30M/1039M build 22-Jun-2015 07:44:30 INFO: ------------------------------------------------------------------------ error 22-Jun-2015 07:44:30 ERROR: Error during Sonar runner execution error 22-Jun-2015 07:44:30 ERROR: Unable to execute Sonar error 22-Jun-2015 07:44:30 ERROR: Caused by: Unable to save file sources error 22-Jun-2015 07:44:30 ERROR: Caused by: -1
Not much use! I thought there was some permission problem, since “Unable to save file sources” usually means that! But there were no permission issues. I then disabled the Cobertura part of the analysis and things were ok, so it was something wrong with the Cobertura part. I then:
- enabled verbose logging — sonar.verbose=true
- enabled full stack trace logging — using the -e switch
- enabled full debug logging with the — using the -X switch
this provided a few more clues.
error 22-Jun-2015 11:09:06 ERROR: Error during Sonar runner execution build 22-Jun-2015 11:09:06 INFO: ------------------------------------------------------------------------ error 22-Jun-2015 11:09:06 org.sonar.runner.impl.RunnerException: Unable to execute Sonar error 22-Jun-2015 11:09:06 at org.sonar.runner.impl.BatchLauncher$1.delegateExecution(BatchLauncher.java:91) error 22-Jun-2015 11:09:06 at org.sonar.runner.impl.BatchLauncher$1.run(BatchLauncher.java:75) error 22-Jun-2015 11:09:06 at java.security.AccessController.doPrivileged(Native Method) error 22-Jun-2015 11:09:06 at org.sonar.runner.impl.BatchLauncher.doExecute(BatchLauncher.java:69) error 22-Jun-2015 11:09:06 at org.sonar.runner.impl.BatchLauncher.execute(BatchLauncher.java:50) error 22-Jun-2015 11:09:06 at org.sonar.runner.api.EmbeddedRunner.doExecute(EmbeddedRunner.java:102) error 22-Jun-2015 11:09:06 at org.sonar.runner.api.Runner.execute(Runner.java:100) error 22-Jun-2015 11:09:06 at org.sonar.runner.Main.executeTask(Main.java:70) error 22-Jun-2015 11:09:06 at org.sonar.runner.Main.execute(Main.java:59) error 22-Jun-2015 11:09:06 at org.sonar.runner.Main.main(Main.java:53) error 22-Jun-2015 11:09:06 Caused by: java.lang.IllegalStateException: Unable to save file sources error 22-Jun-2015 11:09:06 at org.sonar.batch.index.SourcePersister.persist(SourcePersister.java:84) error 22-Jun-2015 11:09:06 at org.sonar.batch.phases.DatabaseModePhaseExecutor.executePersisters(DatabaseModePhaseExecutor.java:165) error 22-Jun-2015 11:09:06 at org.sonar.batch.phases.DatabaseModePhaseExecutor.execute(DatabaseModePhaseExecutor.java:133) error 22-Jun-2015 11:09:06 at org.sonar.batch.scan.ModuleScanContainer.doAfterStart(ModuleScanContainer.java:264) error 22-Jun-2015 11:09:06 at org.sonar.api.platform.ComponentContainer.startComponents(ComponentContainer.java:92) error 22-Jun-2015 11:09:06 at org.sonar.api.platform.ComponentContainer.execute(ComponentContainer.java:77) error 22-Jun-2015 11:09:06 at org.sonar.batch.scan.ProjectScanContainer.scan(ProjectScanContainer.java:235) error 22-Jun-2015 11:09:06 at org.sonar.batch.scan.ProjectScanContainer.scanRecursively(ProjectScanContainer.java:230) error 22-Jun-2015 11:09:06 at org.sonar.batch.scan.ProjectScanContainer.doAfterStart(ProjectScanContainer.java:220) error 22-Jun-2015 11:09:06 at org.sonar.api.platform.ComponentContainer.startComponents(ComponentContainer.java:92) error 22-Jun-2015 11:09:06 at org.sonar.api.platform.ComponentContainer.execute(ComponentContainer.java:77) error 22-Jun-2015 11:09:06 at org.sonar.batch.scan.ScanTask.scan(ScanTask.java:57) error 22-Jun-2015 11:09:06 at org.sonar.batch.scan.ScanTask.execute(ScanTask.java:45) error 22-Jun-2015 11:09:06 at org.sonar.batch.bootstrap.TaskContainer.doAfterStart(TaskContainer.java:135) error 22-Jun-2015 11:09:06 at org.sonar.api.platform.ComponentContainer.startComponents(ComponentContainer.java:92) error 22-Jun-2015 11:09:06 at org.sonar.api.platform.ComponentContainer.execute(ComponentContainer.java:77) error 22-Jun-2015 11:09:06 at org.sonar.batch.bootstrap.GlobalContainer.executeTask(GlobalContainer.java:158) error 22-Jun-2015 11:09:06 at org.sonar.batch.bootstrapper.Batch.executeTask(Batch.java:95) error 22-Jun-2015 11:09:06 at org.sonar.batch.bootstrapper.Batch.execute(Batch.java:67) error 22-Jun-2015 11:09:06 at org.sonar.runner.batch.IsolatedLauncher.execute(IsolatedLauncher.java:48) error 22-Jun-2015 11:09:06 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) error 22-Jun-2015 11:09:06 at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) error 22-Jun-2015 11:09:06 at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) error 22-Jun-2015 11:09:06 at java.lang.reflect.Method.invoke(Method.java:606) error 22-Jun-2015 11:09:06 at org.sonar.runner.impl.BatchLauncher$1.delegateExecution(BatchLauncher.java:87) error 22-Jun-2015 11:09:06 ... 9 more error 22-Jun-2015 11:09:06 Caused by: java.lang.ArrayIndexOutOfBoundsException: -1 error 22-Jun-2015 11:09:06 at java.util.ArrayList.elementData(ArrayList.java:371) error 22-Jun-2015 11:09:06 at java.util.ArrayList.get(ArrayList.java:384) error 22-Jun-2015 11:09:06 at com.google.protobuf.RepeatedFieldBuilder.getBuilder(RepeatedFieldBuilder.java:245) error 22-Jun-2015 11:09:06 at org.sonar.server.source.db.FileSourceDb$Data$Builder.getLinesBuilder(FileSourceDb.java:2911) error 22-Jun-2015 11:09:06 at org.sonar.batch.index.SourceDataFactory.
Now, I could see earlier in the log, that the Cobertura analysis had finished. I could also see that the Cobertura coverage.xml generated ok (this is the file which collates the code coverage info). The next step after creating the coverage.xml file was for the sonar runner to parse it and send a request to Postgres, something had to going wrong at the parsing stage since connecting to Postgres was definitely not an issue (remember everything fine when Cobertura disabled). I knew there was no problem sending the request to Postgres, so thought there must be something odd in the coverage.xml file which meant Sonar runner failed to parse it. As stated, the coverage.xml file details what line number for each class has and hasn’t been covered. Sample:
<class name="com.dublintech.me.ApiLogFilters" filename="com/dublintech/me/ApiLogFilters.groovy" line-rate="0.0" branch-rate="0.0" complexity="0.0">
<methods>
<method name="<clinit>" signature="()V" line-rate="0.0" branch-rate="1.0">
<lines>
<line number="25" hits="0" branch="false">
</line></lines>
</method>
...
</methods></class>
...So what kind of things could make the parsing barf? What about if there was some odd line number in the coverage.xml file? hmmm… To check this, I ran the following grep:
> grep "line number" coverage.xml
This gave too much. What about any negative line numbers?
>grep "line number=\"\-" coverage.xml
Nope, none. Ok go back to exception, look at this line:
java.lang.ArrayIndexOutOfBoundsException: -1
hmmm… If a line number was 0, I wonder could it make some array parsing in the sonar runner throw index out of bounds?
>grep "line number=\"0" coverage.xml
Hit! Time to grep lines before and after and get more info about this file.
>grep -C20 "line number=\"0" coverage.xml
This gave me the culprit. It made no sense to me why Cobertura was saying that linenumber 0 had 0 hits. It was still possible to open the Cobertura html report and view the analysis. Sonar was just barfing when it was parsing it. So I removed this file from Cobertura analysis by adding the following to my build config.
coverage {
xml = true
exclusions = [
"**/com/dublintech/me/MyOddFile*"
]
}I then re-ran and hey presto, everything working. The file wasn’t in the coverage.xml file. This meant the Sonar runner could parse the file and everything was ok.
I like sonar, I like a stable build and I like rapid feedback so yeah I was a happy person when it was working again!
| Reference: | Problems with Cobertura and Sonar 5.1 from our JCG partner Alex Staveley at the Dublin’s Tech Blog blog. |
