Error while importing rubocop report in 9.9 LTS

  • What version are you upgrading from? → 8.9.9 to 9.9.1
  • System information (Operating system, Java version, Database provider/version) → OS Debian Slim Buster, Java 17.01 , Postgres 10
  • What’s the issue you’re facing?

while running an analysis on our staging license before upgrading to the latest LTS, we faced the following issue in one of our ruby projects.

INFO: Importing XXX/report.json
ERROR: No issues information will be saved as the report file '/XXX/report.json' can't be read. 1 is not a valid line offset for pointer. File XXX.rb has 0 character(s) at line 32
java.lang.IllegalArgumentException: 1 is not a valid line offset for pointer. File XXX.rb has 0 character(s) at line 32
	at org.sonar.api.utils.Preconditions.checkArgument(
	at org.sonar.api.batch.fs.internal.DefaultInputFile.checkValid(
	at org.sonar.api.batch.fs.internal.DefaultInputFile.newPointer(
	at org.sonar.api.batch.fs.internal.DefaultInputFile.newRange(
	at org.sonarsource.ruby.externalreport.rubocop.RuboCopSensor.saveIssue(
	at org.sonarsource.ruby.externalreport.rubocop.RuboCopSensor.lambda$importReport$1(
	at org.sonarsource.ruby.externalreport.rubocop.RuboCopJsonReportReader.onOffense(
	at org.sonarsource.ruby.externalreport.rubocop.RuboCopJsonReportReader.lambda$onFile$0(
	at java.base/java.util.ArrayList$ArrayListSpliterator.forEachRemaining(Unknown Source)
	at java.base/$Head.forEach(Unknown Source)
	at org.sonarsource.ruby.externalreport.rubocop.RuboCopJsonReportReader.onFile(
	at java.base/java.util.ArrayList$ArrayListSpliterator.forEachRemaining(Unknown Source)
	at java.base/$Head.forEach(Unknown Source)
	at org.sonarsource.ruby.externalreport.rubocop.RuboCopSensor.importReport(
	at org.sonarsource.ruby.externalreport.rubocop.RuboCopSensor.lambda$reportConsumer$0(
	at org.sonarsource.slang.plugin.AbstractPropertyHandlerSensor.lambda$executeOnFiles$1(
	at java.base/$ForEachOp$OfRef.accept(Unknown Source)
	at java.base/$2$1.accept(Unknown Source)
	at java.base/java.util.ArrayList$ArrayListSpliterator.forEachRemaining(Unknown Source)
	at java.base/ Source)
	at java.base/ Source)
	at java.base/$ForEachOp.evaluateSequential(Unknown Source)
	at java.base/$ForEachOp$OfRef.evaluateSequential(Unknown Source)
	at java.base/ Source)
	at java.base/ Source)
	at org.sonarsource.slang.plugin.AbstractPropertyHandlerSensor.executeOnFiles(
	at org.sonarsource.slang.plugin.AbstractPropertyHandlerSensor.execute(
	at org.sonarsource.ruby.externalreport.rubocop.RuboCopSensor.execute(
	at org.sonar.scanner.sensor.AbstractSensorWrapper.analyse(
	at org.sonar.scanner.sensor.ModuleSensorsExecutor.execute(
	at org.sonar.scanner.sensor.ModuleSensorsExecutor.lambda$execute$1(
	at org.sonar.scanner.sensor.ModuleSensorsExecutor.withModuleStrategy(
	at org.sonar.scanner.sensor.ModuleSensorsExecutor.execute(
	at org.sonar.scanner.scan.SpringModuleScanContainer.doAfterStart(
	at org.sonar.core.platform.SpringComponentContainer.startComponents(
	at org.sonar.core.platform.SpringComponentContainer.execute(
	at org.sonar.scanner.scan.SpringProjectScanContainer.scan(
	at org.sonar.scanner.scan.SpringProjectScanContainer.scanRecursively(
	at org.sonar.scanner.scan.SpringProjectScanContainer.doAfterStart(
	at org.sonar.core.platform.SpringComponentContainer.startComponents(
	at org.sonar.core.platform.SpringComponentContainer.execute(
	at org.sonar.scanner.bootstrap.SpringGlobalContainer.doAfterStart(
	at org.sonar.core.platform.SpringComponentContainer.startComponents(
	at org.sonar.core.platform.SpringComponentContainer.execute(
	at org.sonar.batch.bootstrapper.Batch.doExecute(
	at org.sonar.batch.bootstrapper.Batch.execute(
	at org.sonarsource.scanner.api.internal.batch.BatchIsolatedLauncher.execute(
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
	at java.base/java.lang.reflect.Method.invoke(Unknown Source)
	at org.sonarsource.scanner.api.internal.IsolatedLauncherProxy.invoke(
	at jdk.proxy1/jdk.proxy1.$Proxy0.execute(Unknown Source)
	at org.sonarsource.scanner.api.EmbeddedScanner.doExecute(
	at org.sonarsource.scanner.api.EmbeddedScanner.execute(
	at org.sonarsource.scanner.cli.Main.execute(
	at org.sonarsource.scanner.cli.Main.execute(
	at org.sonarsource.scanner.cli.Main.main(
INFO: Sensor Import of RuboCop issues [ruby] (done) | time=937ms

We depend on using rubocop as a third-party issue report and need this for our reporting to the customers.

We figured out this is mostly raised by rules refering to an empty line or a block comment, so mainly Layout and Style catagory cops.

Up to now we could identifiy the following cops to fail for sure:

Hey there.

Thanks for the report.

I suggest putting together a small sample project that can reproduce the issue (with a real rubocop issue and json report file) so that we can investigate further.

And please no screenshots of logs. :slight_smile:

Here is an example GitLab project with a dummy ruby file and a gitlab-ci.yml configuration with an integrated rubocop analysis. (1.0 KB)

Hope this is helping to get further investigation done!

Hello @a.stalitza,

Thanks for your message. Could you, please, share with me a rubocop repport? Sonar doesn’t execute rubocop, it just reads the report file. So I need the report to understand, what’s not working.

From what I see in the code, we shouldn’t see issues like this. However, maybe something in the report changed and our assumptions aren’t valid anymore.


Hope this is helping out!
report.json (2.0 KB)

Is there any update from your side? We still wait desperately for a solution on this topic as it prevents our upgrade to the latest LTS. Thank you very much in advance.

Hey @a.stalitza,

Yep, I’m working on it. Will get back to you soon.

Please, note, that answering community threads is not our main priority at the moment. We try to provide the best experience we can, however, we can’t give you any guarantee regarding fast answers.


I was able to reproduce the issue, and after some investigation, found out the root cause.

Here you will find the ticket to fix the issue:

Thanks for your valuable feedback.


Thanks for your effort!

I saw that the solution has been implemented and was also linked to a solution version of the SonarSlang repository.

Can you tell us in which version of SonarQube we can expect this bug fix to be released? We are looking forward to be able to upgrade our instance which is still stuck on 8.9.

Thanks a lot in advance