We are working on getting SonarQube fully integrated in our build pipeline (including for pull requests), and it is struggling with some of the files and projects. Some of the ones that failed on SonarLint we have got working on SonarQube, but sometimes it is running our of memory, so we are tweaking the heap size.
One of the ones that initially was failing on SonarLint (when trying to scan the current file) worked when SonarLint did a re-analysis of open files. But when did the re-analysis, I got about 3-4 instances of subprocess.exe crashing.
But also the performance is also a concern, so we are hoping for further improvements that are coming for both SonarLint and SonarQube.
On SonarQube is the analysis of every file slow? or only specific ones that are taking an extremely long time that is impacting the overall time? If the latter you can you add the reproducer option to the scanner configuration: sonar.cfamily.reproducer= "Full path to the .cpp file that is taking a very long time"
This should create a file named sonar-cfamily.reproducer in the project folder. This file will help me in debugging the issue and hopefully fix the issue.
are these consistent crashes? The fact that they succeeded before is worrisome. Did you change anything in the code between the two-run?
Hi @magicmalcsiress, just a heads up if you’re still using the environment variable SONAR_INTERNAL_CFAMILY_ANALYSIS_TIMEOUT_MS – please be advised that we’ve released SLVS 4.23 where we’ve renamed the variable. However, we’ve implemented numerous performance improvements, so the settings this environment variable should not be needed.