ERROR: isAlive was interrupted when applying all findbugs rules into my existing sonarway copy profile to scan a monolithic project

[emma-qi-qi]

Issue Description

Applying all findbugs rules and findbugs security rules into my existing sonarway copy profile, when scan project in jenkins pipeline, the scan process hang up and following error occured. By the way, the scan can be successful before updating sonarqube from 7.9.6 to 9.9.4, findbugs from 4.2.3 to 4.2.9. Also if I change the quality profile to Sonar way, it can be successful with sonarqube 9.9.4. So I think the problem has something to do with findbugs plugin.

Aux: /data/jenkins/workspace/aaa_SONAR/build/classes/src Aux: /data/jenkins/workspace/aaa_SONAR/.scannerwork/findbugs/annotations.jar Aux: /data/jenkins/workspace/aaa_SONAR/.scannerwork/findbugs/jsr305.jar ERROR: isAlive was interrupted java.lang.InterruptedException: null at java.base/java.util.concurrent.CompletableFuture.reportGet(Unknown Source) at java.base/java.util.concurrent.CompletableFuture.get(Unknown Source) at java.net.http/jdk.internal.net.http.HttpClientImpl.send(Unknown Source) at java.net.http/jdk.internal.net.http.HttpClientFacade.send(Unknown Source) at org.sonar.plugins.javascript.eslint.EslintBridgeServerImpl.isAlive(EslintBridgeServerImpl.java:331) at org.sonar.plugins.javascript.eslint.EslintBridgeServerImpl.heartbeat(EslintBridgeServerImpl.java:121) at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source) at java.base/java.util.concurrent.FutureTask.runAndReset(Unknown Source) at java.base/java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(Unknown Source) at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source) at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) at java.base/java.lang.Thread.run(Unknown Source)

Environment

| Component | Version | sonarqube 9.9.4 sonar-scanner 5.0.1 sonar-findbugs plugin 4.2.9 ant 1.9.6 JDK 1.6.7 Set SONAR_SCANNER_OPTS=-Xmx10G

[gtoison]

Have you tried setting the sonar.findbugs.timeout to something higher than the default value? New bug detectors are frequently added and updated so it's possible that the analysis is taking longer

[emma-qi-qi]

Yes，I have set the sonar.findbugs.timeout to 7200000. The scan process always hang for serveral hours, I killed the pipeline manually.

[gtoison]

Can you please try to find out what code is running (or waiting) at the end? One way is to capture a thread dump of the java process. The stacktrace you have posted is about a built-in sonar plugin (org.sonar.plugins.javascript.eslint.EslintBridgeServerImpl) but you're saying that the problem happens when updating SpotBugs, so I'm not sure what's going on.

https://www.baeldung.com/java-thread-dump

Can you please also investigate the memory usage of the process? I would need to know if maybe the process is about to run out of memory. A healthy memory usage chart would be something like that:

[emma-qi-qi]

Hi, gtoison. I tried to use a lower version spotbugs plugin 4.2.5, and set these parameters to reduce the scan time : -Dsonar.findbugs.analyzeTests=false -Dsonar.findbugs.effort=min -Dsonar.findbugs.reportLevel=high -Dsonar.findbugs.confidenceLevel=high The scan run outof memory at last:

java.lang.OutOfMemoryError: Java heap space Dumping heap to /home/appadmin/qifj/scan_dump/java_pid16523.hprof ... Heap dump file created [17721672072 bytes in 203.374 secs] Exception in thread "process reaper" java.lang.OutOfMemoryError: Java heap space ERROR: Error in thread nodejs-stream-consumer java.lang.OutOfMemoryError: Java heap space

ERROR: Java heap space java.lang.OutOfMemoryError: Java heap space

Atteched is the dump info by jstack command. dump.txt

[gtoison]

Thank you for the thread dump, so it looks like it was doing an injection taint analysis when the dump was captured. This is from the findsecbugs plugin, could you please try disabling all the findsecbugs rules in your sonar quality profile?

I would also be interested to see the .hprof dump to check what exactly is taking so much memory, it would be great if you could share it.

[emma-qi-qi]

Sorry, the .hprof dump file is too big, almost 17G, and can not transfer to the network due to company restrictions. I'll disable all findsecbugs rules and have a try.

[emma-qi-qi]

By the way, I wonder what is the difference of these four profiles, what is the difference between findbugs rules and Sonar way? What is the best practice to use these rules? I created a copy of sonarway and activated all findbugs critical/blocker rules. FindBugs FindBugs + FB-Contrib FindBugs Security Audit FindBugs Security Minimal

[gtoison]

Sonar Way is the built-in SonarQube quality profile, it uses rules implemented by SonarSource, the makers of SonarQube.

FindBugs is the old name of SpotBugs, it is a separate tools with its own bug detectors. It is also available as a plugin for SonarQube. That's how you are using it, but you could also use SonarQube from gradle, maven, ant or standalone. So there's some overlap between SonarWay and SpotBugs, because they are often used separately.

SpotBugs itself has plugins, notably FindSecBugs and FbContrib, providing additional bug detectors. The SonarQube SpotBugs plugin is bundled with FindSecBugs and FbContrib and you can use preset quality profile to enable them. FindSecBugs has the audit and minimal profiles to be more or less thourough in the security analysis of the code.

Note that currently FindSecBug and FbContrib will run all their respective bug detectors if at least one of their rules is enabled. So you need to disable all FindSecBug rules to test if that solves the memory problem.

What is the best practice to use these rules?

It's a bit hard to answer that question as it depends a lot on the team organization, blocker rules might not be relevant to some teams and vice versa some minor rules might be important. One way is to enable everything and then disable the rules that are not relevant or less urgent, but better discuss this with the developers team.