SonarQube 9.6.1 Failure - NullPointerException at ScmInfoRepositoryImpl.removeAuthorAndRevision

[Will (WillJudd)]

Hello,

Reporting a bug in SonarQube 9.6.1 Enterprise Edition using the Sonar Maven plugin and BitBucket Server v7.17.10.

The instance was upgraded from 9.4 to 9.6.1 over 3 weeks ago and there have been more than 1500 analyses run since then including on new branches.

However, running an analysis on a new branch has failed 3 times in the last 24 hours on 3 different repositories.

We have:

a) Re-run the analysis on the branch multiple times - problem remains
b) Removed the local cache and restarted the server, waited till all data was loaded and run again - problem remains
c) Disabled the scm sensor on the project and run again - problem remains
d) Explicitly set git as the sensor for the project and run again - problem remains

The message displayed is:

The Background Tasks Error Details log gives:

Error Details
org.sonar.ce.task.projectanalysis.component.VisitException: Visit of Component {key=Vitality:a249ccb9:pom.xml:BRANCH:feature/fix_int_tst_and_covarage,type=FILE} failed
	at org.sonar.ce.task.projectanalysis.component.VisitException.rethrowOrWrap(VisitException.java:44)
	at org.sonar.ce.task.projectanalysis.component.VisitorsCrawler.visit(VisitorsCrawler.java:71)
	at org.sonar.ce.task.projectanalysis.component.VisitorsCrawler.visitChildren(VisitorsCrawler.java:107)
	at org.sonar.ce.task.projectanalysis.component.VisitorsCrawler.visitImpl(VisitorsCrawler.java:94)
	at org.sonar.ce.task.projectanalysis.component.VisitorsCrawler.visit(VisitorsCrawler.java:69)
	at org.sonar.ce.task.projectanalysis.step.ExecuteVisitorsStep.execute(ExecuteVisitorsStep.java:51)
	at org.sonar.ce.task.step.ComputationStepExecutor.executeStep(ComputationStepExecutor.java:80)
	at org.sonar.ce.task.step.ComputationStepExecutor.executeSteps(ComputationStepExecutor.java:71)
	at org.sonar.ce.task.step.ComputationStepExecutor.execute(ComputationStepExecutor.java:58)
	at org.sonar.ce.task.projectanalysis.taskprocessor.ReportTaskProcessor.process(ReportTaskProcessor.java:75)
	at org.sonar.ce.taskprocessor.CeWorkerImpl$ExecuteTask.executeTask(CeWorkerImpl.java:212)
	at org.sonar.ce.taskprocessor.CeWorkerImpl$ExecuteTask.run(CeWorkerImpl.java:194)
	at org.sonar.ce.taskprocessor.CeWorkerImpl.findAndProcessTask(CeWorkerImpl.java:160)
	at org.sonar.ce.taskprocessor.CeWorkerImpl$TrackRunningState.get(CeWorkerImpl.java:135)
	at org.sonar.ce.taskprocessor.CeWorkerImpl.call(CeWorkerImpl.java:87)
	at org.sonar.ce.taskprocessor.CeWorkerImpl.call(CeWorkerImpl.java:53)
	at com.google.common.util.concurrent.TrustedListenableFutureTask$TrustedFutureInterruptibleTask.runInterruptibly(TrustedListenableFutureTask.java:131)
	at com.google.common.util.concurrent.InterruptibleTask.run(InterruptibleTask.java:74)
	at com.google.common.util.concurrent.TrustedListenableFutureTask.run(TrustedListenableFutureTask.java:82)
	at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
	at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
	at java.base/java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:304)
	at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
	at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
	at java.base/java.lang.Thread.run(Thread.java:829)
Caused by: java.lang.IllegalStateException: Fail to process issues of component 'Vitality:a249ccb9:pom.xml:BRANCH:feature/fix_int_tst_and_covarage'
	at org.sonar.ce.task.projectanalysis.issue.IntegrateIssuesVisitor.visitAny(IntegrateIssuesVisitor.java:106)
	at org.sonar.ce.task.projectanalysis.component.TypeAwareVisitorWrapper.visitAny(TypeAwareVisitorWrapper.java:77)
	at org.sonar.ce.task.projectanalysis.component.VisitorsCrawler.visitNode(VisitorsCrawler.java:114)
	at org.sonar.ce.task.projectanalysis.component.VisitorsCrawler.visitImpl(VisitorsCrawler.java:97)
	at org.sonar.ce.task.projectanalysis.component.VisitorsCrawler.visit(VisitorsCrawler.java:69)
	... 23 more
Caused by: java.lang.NullPointerException
	at org.sonar.ce.task.projectanalysis.scm.ScmInfoRepositoryImpl.removeAuthorAndRevision(ScmInfoRepositoryImpl.java:104)
	at java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:195)
	at java.base/java.util.Spliterators$ArraySpliterator.forEachRemaining(Spliterators.java:948)
	at java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:484)
	at java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:474)
	at java.base/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:550)
	at java.base/java.util.stream.AbstractPipeline.evaluateToArrayNode(AbstractPipeline.java:260)
	at java.base/java.util.stream.ReferencePipeline.toArray(ReferencePipeline.java:517)
	at org.sonar.ce.task.projectanalysis.scm.ScmInfoRepositoryImpl.removeAuthorAndRevision(ScmInfoRepositoryImpl.java:99)
	at org.sonar.ce.task.projectanalysis.scm.ScmInfoRepositoryImpl.generateAndMergeDb(ScmInfoRepositoryImpl.java:119)
	at org.sonar.ce.task.projectanalysis.scm.ScmInfoRepositoryImpl.getScmInfoForComponent(ScmInfoRepositoryImpl.java:74)
	at java.base/java.util.HashMap.computeIfAbsent(HashMap.java:1134)
	at org.sonar.ce.task.projectanalysis.scm.ScmInfoRepositoryImpl.getScmInfo(ScmInfoRepositoryImpl.java:65)
	at org.sonar.ce.task.projectanalysis.issue.IssueCreationDateCalculator.getScmInfo(IssueCreationDateCalculator.java:154)
	at org.sonar.ce.task.projectanalysis.issue.IssueCreationDateCalculator.getDateOfLatestChange(IssueCreationDateCalculator.java:144)
	at org.sonar.ce.task.projectanalysis.issue.IssueCreationDateCalculator.backdateIssue(IssueCreationDateCalculator.java:112)
	at org.sonar.ce.task.projectanalysis.issue.IssueCreationDateCalculator.onIssue(IssueCreationDateCalculator.java:84)
	at org.sonar.ce.task.projectanalysis.issue.IssueVisitors.onIssue(IssueVisitors.java:41)
	at org.sonar.ce.task.projectanalysis.issue.IntegrateIssuesVisitor.processIssue(IntegrateIssuesVisitor.java:160)
	at org.sonar.ce.task.projectanalysis.issue.IntegrateIssuesVisitor.lambda$processIssues$0(IntegrateIssuesVisitor.java:111)
	at java.base/java.util.ArrayList.forEach(ArrayList.java:1541)
	at org.sonar.ce.task.projectanalysis.issue.IntegrateIssuesVisitor.processIssues(IntegrateIssuesVisitor.java:111)
	at org.sonar.ce.task.projectanalysis.issue.IntegrateIssuesVisitor.visitAny(IntegrateIssuesVisitor.java:100)
	... 27 more

Please advise if this is a bug, whether there is a workaround.

Thanks,

Will

[Will (WillJudd)]

Just to update.

Once this problem starts with the branch analyses on a repository, then all future branch analyses on that repository fail.

Running this analysis for the branch on a staging instance with the same setup is successful.

Note that the same problem is also reported by Guarav Singh in his comment here:

9.6.1 developer: org.sonar.ce.task.projectanalysis.component.VisitException

Hey @mmadeira , Could you share what type of new code period strategy are you using in SQ? Are you using git? Could you also share scanner execution logs from that failure?

This seems like a data problem, such as from a failed earlier process to harvest scm information. I see the comment on the file with the method that is throwing the exception in the github repo about Sonar using existing data in the database.

It would be good to understand the root cause of this and whether this can be fixed by either removing the analysis and analysing every branch again, or removing all but the main branch analysis (to retain the history).

Presently this is blocking our releases.

Any help appreciated.

Thanks,

Will

[Will (WillJudd)]

Attempting to remove all branch analyses other than master and develop via the API and then reattempting analysis on this branch did not resolve it.

This was only resolved by deleting the entire project and analysing it again, losing the history.

Because the cause has not been determined, we are concerned it could happen again.

[Will (WillJudd)]

Unfortunately the solution of clearing disk space was not the resolution for us.

The resolution for this is discussed / continued in this thread:

9.6.1 developer: org.sonar.ce.task.projectanalysis.component.VisitException

That’s part of the problem. The scanner should be able to collect blame for all lines. Is it possible that there are uncommitted changes to those files when the scanner runs?