Sonar Gradle Scans failing with heap out of space error

We are using sonarqube verion 10.4(enterprise sonar) deployed via zip . We facing an issue with the analysis of one our projects . While it is absolute working fine on our another instance which is 10.0 (developer edition).
On the 10.4 version , the project analysis never done and it says java heap space is out of space.
We tried with giving 22g as well but stilll it runs for forme than 8 hours and then fails with the error

  • Out of memory: Java heap space (This problem is reported because OutOfMemoryError has been found in the build log text); gradle

We are using java 17 in both the cases for project .

log.txt (63.7 KB)

Additional inofrmation:

log.txt (63.7 KB)
fro increasing ram we are using :
Sonar Gradel plugin :


Could we have a full --info analysis log, please? That will help us understand more precisely where the error is happening.


How do we get the full log in sonar gradle plugin , can you help we with that plz. I mean how do we pass --info.


You’ll add --info to the gradle commandline.


you mean the log from gradle right?


Yes, I’m looking for an --info-level log from the Gradle analysis command.


I have initiate the build now. Mean while this is the log from a recent build.
We have findbugs plugin earlier on the server . But removed that and then run this build .
Also for your infrormation the project is analyzed perfectly fine on 10.0 where as it is failing on 10.4

log_new.txt (57.6 KB)

the usual runtime for this build is 1.2 hours on 10.0 but its running endless on 10.4

Here is the build log with info.
WebCTRL_SR23_PI4_45.log (3.8 MB)


Thanks for the log. What I’m seeing in it is not an OOM error, but that the server stopped the job, I suppose because it timed out after >2.5h?

[10:32:06]W: [Step 2/3] Stopping build on agent. Reason: stop build command from the server

I would ask if you could increase the timeout, but >1.5h without output doesn’t look right to me

[08:48:05] :		 [:sonar] Too high simulation costs for sink in /C:/buildAgent/BuildAgent/work/225a9ab552bb5d96/modules/core/src/main/java/com/controlj/green/core/data/ This sink will not be analyzed any further.
[10:32:06]W:	 [Step 2/3] Stopping build on agent. Reason: stop build command from the server

So I’m going to flag this for more expert eyes.


yes we stopped due to the timeout but will run it again if needed.
We are getting this and getting struck.

Taint analysis for java: Starting

[08:44:28] : [:sonar] Too high simulation costs for sink in /C:/buildAgent/BuildAgent/work/225a9ab552bb5d96/modules/core/src/main/java/com/controlj/green/core/data/ This sink will not be analyzed any further.

Thank you

Hi Ajay,

Thanks a lot for your message and the logs you provided: it seems that the java security sensor hung unexpectedly during the analysis of your webctrl_webctrl module.

Still, it is hard to imagine the code structure that causes the issue and why the sensor gets stuck.

Is the project you are analyzing an open-source one, by any chance?
If not, would you be willing to zip and share the content of the C:\buildAgent\BuildAgent\work\225a9ab552bb5d96\working\build\webctrl_webctrl\sonar\ucfg2\java ?
(I will send you a direct message to allow you to send this zip privately)

This folder’s content will allow us to run the analysis part of the java security scan on our end and better understand the issue.

Fixing this can take time. To unlock the situation, I see two options:

  • as a first try, try to ignore the file
    You can achieve this for example with the analysis parameter (you may need to adapt the path depending on where is the analysis run)

  • If this does not fix the analysis you can create a specific profile for the project with the following taint rules disabled - this will skip the whole taint analysis :
    S2076, S2078, S2083, S2091, S2631, S3649, S5131, S5135, S5144, S5145, S5146, S5167, S5334, S6096

I hope this helps, let me know.


Hi Renaud ,
We will try first option but , is it a good option to disable taint rules ?
This is our commercial product , so will check with the team whether we can share the folder that you are requesting .
Will update you on the options.


Ajay Nunna

Global Product Security

Technical Specialist

Carrier Technologies India Limited

Mobile: +91 8978408281

Hello Ajay,

disabling taint rules is not ideal, but it will allow you to still perform the analysis of your code using all the other sensors that cover quality and sub-part of the security issues.



Hi Renaud,

I am Ajay’s Teammate! working on the same project.
I want to inform you that we tried updating the RAM size earlier to 60GB and temporarily we could run this project.

But now as we had recent developments in the code we have started getting the same issue again.
Out of memory: Java heap space error

Even though we have tried updating the RAM size to 120 GB we are unable to resolve the issue.

We decided to work on the solutions given by you on this and we did tried first option to ignore
-Dsonar.exclusions=“modules/core/src/main/java/com/controlj/green/core/data/” but this solution did not help us

then we tried disabling the given rules S2076, S2078, S2083, S2091, S2631, S3649, S5131, S5135, S5144, S5145, S5146, S5167, S5334, S6096 and still we ran out with same error.

Project uses Gradle v8.7 and java17

attached a snipped to logs for your reference.
logsctrl.txt (11.2 KB)

Kindly help us.

  • Altaf

Hi Altaf,

Can we have the full analysis log, starting from the analysis command, please?

Also, can you confirm your versions of

  • SonarQube
  • Gradle
  • SonarScanner for Gradle


Hi Ann,

Can you request logs in a private message, I can share the logs in there.
also, we have

Gradle 8.7
Sonarscanner for gradle 3.3


Hi Altaf,

Feel free to redact as necessary.


Hi Altaf,

As a first step to avoid the OOM, I think it could be worth to try to change your jvm max heap size settings. In the log it seems it is set to 512M.
Having a lot of RAM does not help much if your max heap size is not updated accordingly.

Can you check your file (usually located at the root of the project) for a property called org.gradle.jvmargs ?
Check if, in the value, there is a -Xmx<something> entry,
if yes replace it by -Xmx2g
if not, please append -Xmx2g to the value (space is separator)
You should see messages in the log related to Xmx showing increased value.

I hope this will help, let us know.

Best regards,


Hi @renaud.tognelli ,

We have tried with -Xmx2g and it did not work for us we then modified it to
-Dorg.gradle.jvmargs=-Xmx8G and it passes for us with below taint rules disabled.

S2076, S2078, S2091, S3649, S5135, S5145, S5334, S6096

Please let us know if this is a bug and can be resolved in newer sonarqube versions.


Hi Altaf,

it is hard to tell if it is a bug or not, 8g is quite a high value but depending on the size of the project, security analysis can require that amount of memory.

Did you try other values between 2g and 8g ?

The good news is that you can adapt the server memory accordingly, with some extra marging, you can probably reduce it to 12g

Do you have the logs of the successful analysis?
It can help us to spot if this is a bug.

Specifically the lines after Sensor JavaSecuritySensor [security] ?

Best regards,