Sonarcloud analysis get stuck on the UCFGs simutaled step

SonarQube Cloud
1
  • ALM used: GitHub
  • CI system used: Azure DevOps
  • Scanner command used when applicable: --debug -Xmx4096m
  • Languages of the repository: Typescript
  • Only if the SonarCloud project is public, the URL
    • And if you need help with pull request decoration, then the URL to the PR too
  • Error observed (wrap logs/code around with triple quotes ``` for proper formatting)
    On a large monorepo the sonarcloud scan get stuck on the UCFGs simutaled step.
    Here is the last piece of the log:
13:43:05.778 INFO  6202 / 84853 UCFGs simulated, memory usage: 1976 MB
13:43:14.860 INFO  6356 / 84853 UCFGs simulated, memory usage: 1980 MB
13:44:02.711 DEBUG Shutting down the worker
13:44:02.712 INFO  Rule                          | Time (ms) | Relative
13:44:02.712 INFO  :-----------------------------|----------:|--------:
13:44:02.712 INFO  ucfg                          | 19137.298 |    93.7%
13:44:02.712 INFO  internal-cognitive-complexity |   751.931 |     3.7%
13:44:02.712 INFO  internal-symbol-highlighting  |   539.603 |     2.6%
13:44:02.712 DEBUG The worker thread exited with code 0
13:44:02.712 DEBUG The bridge server shut down
13:44:02.712 INFO  Rule | Time (ms) | Relative
13:44:02.712 INFO  :----|----------:|--------:
13:47:58.745 INFO  6422 / 84853 UCFGs simulated, memory usage: 1976 MB
13:50:34.306 INFO  6460 / 84853 UCFGs simulated, memory usage: 1979 MB
```
2

Hey there!

As documented, can you try bumping up sonar.javascript.node.maxspace (default 2048) to a higher value, like 4096?

3

Thanks for the suggestion but unfortunately it did not solved my issue.
I set it to 8192 in my sonar-project.properties file, but I still get a never ending scan.


14:00:14.683 INFO  6013 / 89212 UCFGs simulated, memory usage: 1982 MB
14:01:19.698 INFO  Time spent writing ucfgs 3757ms
14:13:46.896 INFO  6050 / 89212 UCFGs simulated, memory usage: 1979 MB
14:19:49.422 INFO  6081 / 89212 UCFGs simulated, memory usage: 1979 MB

I think we reached some limits, the only way to get the scan working is to split it in several projects.

4

Hey @eboureau

I’m not so sure we’ve reached a limit yet. It turns out I actually had some bad information (my fault) – the process we should try to increase the memory for is the underlying Java process that runs the scanner, not the spun-off node process used for Javascript analysis (and generating UCFGs).

With that in mind, I suggest:

  • Removing sonar.javascript.node.maxspace
  • Setting a SONAR_SCANNER_JAVA_OPTS environment variable in your Pipeline. Try a value of -Xmx4g to start. You can also optionally set this as an analysis parameter (sonar.scanner.javaOpts). It’s documented here.
1 Like
5

Thank you, it seems to fix the issue.
I was initially passing this parameter in the SONAR_SCANNER_OPTS env var which obviously does not work.

1 Like