IssueList remains empty while overview show bugs and smells

Must-share information:

  • which versions are you using
    • sonarqube-developer-8.3.1.34397 (Linux) using the embedded database
    • sonar-scanner-4.3.0.2102-linux
    • build-wrapper, version 6.9 (linux-x86)
  • what are you trying to achieve
    Analyze a C/C++ project (evaluation)
  • what have you tried so far to achieve this
    I’m trying to set up sonarcube for a C/C++ project. After some searching and a bit sweat I was able to have the project analyzed, good! It detected a few bugs and codesmells, which I can see in the overview (this seems to indicate that the analysis phase worked fine). But when I click to see more details, the list of issues remains empty. In fact the entire “issues” tab is empty and says “No Issues. Hooray!”

Problem to be resolved: how do I actually get to see the issues in the issuelist?

I found this backtrace in the ce.log file:

2020.06.08 13:35:33 ERROR ce[AXKTtr4Y2E3QqzLTPFYy][o.s.c.t.CeWorkerImpl] Failed to execute task AXKTtr4Y2E3QqzLTPFYy
java.lang.IllegalStateException: Unrecoverable indexation failures: 1277 errors among 1277 requests
	at org.sonar.server.es.IndexingListener$1.onFinish(IndexingListener.java:39)
	at org.sonar.server.es.BulkIndexer.stop(BulkIndexer.java:122)
	at org.sonar.server.component.index.ComponentIndexer.delete(ComponentIndexer.java:165)
	at org.sonar.ce.task.projectanalysis.purge.IndexPurgeListener.onComponentsDisabling(IndexPurgeListener.java:41)
	at org.sonar.db.purge.PurgeCommands.purgeDisabledComponents(PurgeCommands.java:181)
	at org.sonar.db.purge.PurgeDao.purgeDisabledComponents(PurgeDao.java:101)
	at org.sonar.db.purge.PurgeDao.purge(PurgeDao.java:63)
	at org.sonar.ce.task.projectanalysis.purge.ProjectCleaner.purge(ProjectCleaner.java:60)
	at org.sonar.ce.task.projectanalysis.purge.PurgeDatastoresStep.execute(PurgeDatastoresStep.java:54)
	at org.sonar.ce.task.step.ComputationStepExecutor.executeStep(ComputationStepExecutor.java:81)
	at org.sonar.ce.task.step.ComputationStepExecutor.executeSteps(ComputationStepExecutor.java:72)
	at org.sonar.ce.task.step.ComputationStepExecutor.execute(ComputationStepExecutor.java:59)
	at org.sonar.ce.task.projectanalysis.taskprocessor.ReportTaskProcessor.process(ReportTaskProcessor.java:81)
	at org.sonar.ce.taskprocessor.CeWorkerImpl$ExecuteTask.executeTask(CeWorkerImpl.java:209)
	at org.sonar.ce.taskprocessor.CeWorkerImpl$ExecuteTask.run(CeWorkerImpl.java:191)
	at org.sonar.ce.taskprocessor.CeWorkerImpl.findAndProcessTask(CeWorkerImpl.java:158)
	at org.sonar.ce.taskprocessor.CeWorkerImpl$TrackRunningState.get(CeWorkerImpl.java:133)
	at org.sonar.ce.taskprocessor.CeWorkerImpl.call(CeWorkerImpl.java:85)
	at org.sonar.ce.taskprocessor.CeWorkerImpl.call(CeWorkerImpl.java:53)
	at com.google.common.util.concurrent.TrustedListenableFutureTask$TrustedFutureInterruptibleTask.runInterruptibly(TrustedListenableFutureTask.java:125)
	at com.google.common.util.concurrent.InterruptibleTask.run(InterruptibleTask.java:69)
	at com.google.common.util.concurrent.TrustedListenableFutureTask.run(TrustedListenableFutureTask.java:78)
	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:835)

Hi,

Even without the stacktrace (thanks for including it!) I knew that you were having ES problems, because the Issues page is populated from the Elasticsearch indices. Now the question is the extent of your ES problems. Were there any other stacktraces in your log?

Clearly you have a bad index. You can fix that by stopping the server and deleting $SONARQUBE-HOME/data/es6. When you start the server back up the indices will be rebuilt automatically. However, you should keep an eye on this log while that’s happening. It’s possible that the indices are bad because ES locked them because it didn’t have enough free disk space to make it happy. If that’s the case, you’ll need to free up some additional disk space before this will work.

 
HTH,
Ann

1 Like

Hi Ann,

Thanks a lot for your fast answer.

You’re right, the es.log indicated that eleasticsearch was running out of diskspace, even with over 13GB free diskspace. Increasing the free diskspace from 3.2% to 6% made elasticsearch happier.

2020.06.08 14:57:24 WARN  es[][o.e.c.r.a.DiskThresholdMonitor] flood stage disk watermark [95%] exceeded on [Ftyy-hidQYG0GasauYrNrg][sonarqube][/home/rv/projects/2020/0608-sonarqube/sonarqube-8.3.1.34397/data/es6/nodes/0] free: 13.1gb[3.2%], all indices on this node will be marked read-only

At that point, simply deleting the es6 folder combined with a restart fixed the issue.

Thanks!

Ruben

1 Like

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.