Java Heap Error when try to execute sonar cloud scan

  • ALM used : GitHub

  • CI system used : Github actions

  • Languages of the repository : Java

  • Error observed
    This was working without an issue for several months and for around November 20th, it started to give following two error for the sonarcloud scan workflow. There was no changes done to the sonar configurations.

Taint analysis starting. Entrypoints: 16
Running symbolic analysis for 'JAVA'
Problem in daemon expiration check

java.lang.OutOfMemoryError: Java heap space

> Task :sonarqube FAILED
:sonarqube (Thread[Execution worker for ':',5,main]) completed. Took 11 mins 14.911 secs.

Deprecated Gradle features were used in this build, making it incompatible with Gradle 6.0.
Use '--warning-mode all' to show the individual deprecation warnings.
See https://docs.gradle.org/5.4/userguide/command_line_interface.html#sec:command_line_warnings
387 actionable tasks: 223 executed, 164 from cache

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':sonarqube'.
> Java heap space: failed reallocation of scalar replaced objects
11:58:23.693579 Variable type analysis: done
Analyzing 39504 ucfgs to detect vulnerabilities.
All rules entrypoints : 16
Retained UCFGs : 6537
Taint analysis starting. Entrypoints: 16
Running symbolic analysis for 'JAVA'


> Task :sonarqube FAILED
:sonarqube (Thread[Daemon worker,5,main]) completed. Took 8 mins 9.405 secs.
FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':sonarqube'.
> Java heap space

* Try:
Run with --stacktrace option to get the stack trace. Run with --debug option to get more log output. Run with --scan to get full insights.

Can I get your help regarding how to solve this issue and why this started to appear recently?

@Karim_El_Ouerghemmi I saw similar post which here. I tried setting SONAR_SCANNER_OPTS in the workflow yaml file but it was not successful. Can you help me to find a solution.

Hey @sahanhe

The date you reported (November 20th) is pretty close to when a new version of our security analysis was deployed to SonarCloud (I believe on November 21st).

It could be that allocating more memory could do the trick: What values did you try using for SONAR_SCANNER_OPTS

And, we should be aware internally if memory utilization jumped, as I think there’s less control over memory in pipelines like GitHub Actions (it’s not as simple as scaling a self-hosted server). I’ll flag this for attention.

Yes @Colin , I tried to increase the memory usage up to 8GB but it wasn’t successful.

- name: Build with Gradle
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} 
          SONAR_TOKEN: ${{ secrets.SONAR_TOKEN }}
        if: "${{ env.SONAR_TOKEN != '' }}"
        run: |
          export DISPLAY=':99.0'
          export SONAR_SCANNER_OPTS="-Xmx8G"
          /usr/bin/Xvfb :99 -screen 0 1024x768x24 > /dev/null 2>&1 &
          ./gradlew build sonarqube --info --max-workers=2 --scan --no-daemon -x test -x check 
          find ~/.gradle/caches/ -name "*.lock" -type f -delete

Hi @Colin,
As mentioned here this problem is a result of additional JS libraries. Since our project doesn’t use javascript, is there a workaround to skip these libraries (or skip the JS language itself) or use a previous version of sonarcloud to run the workflow?

Hey @sahanhe

The crash in your case seems to happen during JAVA analysis. It has nothing to do with JS so no need to skip it.

SONAR_SCANNER_OPTS is for when the normal scanner CLI is used. In your case, for gradle, you should look into how to increase the heap size given to Java through gradle. Can you try export GRADLE_OPTS="-Xmx4g" ?