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.
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.
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?