CI system used: Azure DevOps, using ubuntu-latest, Microsoft hosted agents
Scanner command used when applicable: SonarCloudAnalyze@1
Languages of the repository: C#, Typescript
Error observed
2023-10-10T09:51:05.1245637Z 09:51:05.123 DEBUG: the bridge server closed
2023-10-10T09:51:05.1245991Z 09:51:05.123 INFO: Time spent writing ucfgs 80ms
2023-10-10T09:51:05.6583735Z 09:51:05.657 INFO: ------------------------------------------------------------------------
2023-10-10T09:51:05.6592770Z 09:51:05.659 INFO: EXECUTION FAILURE
2023-10-10T09:51:05.6600854Z 09:51:05.659 INFO: ------------------------------------------------------------------------
2023-10-10T09:51:05.6610981Z 09:51:05.660 INFO: Total time: 9:12.152s
2023-10-10T09:51:05.7434418Z 09:51:05.742 INFO: Final Memory: 27M/100M
2023-10-10T09:51:05.7435742Z 09:51:05.742 INFO: ------------------------------------------------------------------------
2023-10-10T09:51:05.7444467Z ##[error]09:51:05.742 ERROR: Error during SonarScanner execution
java.lang.OutOfMemoryError: Java heap space
at java.base/java.io.UnixFileSystem.resolve(UnixFileSystem.java:118)
at java.base/java.io.File.<init>(File.java:263)
at java.base/java.io.File.listFiles(File.java:1274)
at org.sonar.plugins.javascript.bridge.TsConfigProvider$LookupTsConfigProvider.tsconfigs(TsConfigProvider.java:176)
at org.sonar.plugins.javascript.bridge.TsConfigProvider.tsconfigs(TsConfigProvider.java:94)
at org.sonar.plugins.javascript.bridge.TsConfigProvider.getTsConfigs(TsConfigProvider.java:89)
at org.sonar.plugins.javascript.bridge.JsTsSensor.analyzeFiles(JsTsSensor.java:109)
at org.sonar.plugins.javascript.bridge.AbstractBridgeSensor.execute(AbstractBridgeSensor.java:73)
at org.sonar.scanner.sensor.AbstractSensorWrapper.analyse(AbstractSensorWrapper.java:62)
at org.sonar.scanner.sensor.ModuleSensorsExecutor.execute(ModuleSensorsExecutor.java:75)
at org.sonar.scanner.sensor.ModuleSensorsExecutor.lambda$execute$1(ModuleSensorsExecutor.java:48)
at org.sonar.scanner.sensor.ModuleSensorsExecutor$$Lambda$1252/0x00007f9d5c875720.run(Unknown Source)
2023-10-10T09:51:05.7447144Z 09:51:05.742 ERROR: Error during SonarScanner execution
2023-10-10T09:51:05.7447340Z java.lang.OutOfMemoryError: Java heap space
2023-10-10T09:51:05.7447562Z at java.base/java.io.UnixFileSystem.resolve(UnixFileSystem.java:118)
2023-10-10T09:51:05.7447786Z at java.base/java.io.File.<init>(File.java:263)
2023-10-10T09:51:05.7448146Z at java.base/java.io.File.listFiles(File.java:1274)
2023-10-10T09:51:05.7448438Z at org.sonar.plugins.javascript.bridge.TsConfigProvider$LookupTsConfigProvider.tsconfigs(TsConfigProvider.java:176)
2023-10-10T09:51:05.7448763Z at org.sonar.plugins.javascript.bridge.TsConfigProvider.tsconfigs(TsConfigProvider.java:94)
2023-10-10T09:51:05.7449077Z at org.sonar.plugins.javascript.bridge.TsConfigProvider.getTsConfigs(TsConfigProvider.java:89)
2023-10-10T09:51:05.7449381Z at org.sonar.plugins.javascript.bridge.JsTsSensor.analyzeFiles(JsTsSensor.java:109)
2023-10-10T09:51:05.7449673Z at org.sonar.plugins.javascript.bridge.AbstractBridgeSensor.execute(AbstractBridgeSensor.java:73)
2023-10-10T09:51:05.7449989Z at org.sonar.scanner.sensor.AbstractSensorWrapper.analyse(AbstractSensorWrapper.java:62)
2023-10-10T09:51:05.7450291Z at org.sonar.scanner.sensor.ModuleSensorsExecutor.execute(ModuleSensorsExecutor.java:75)
2023-10-10T09:51:05.7450592Z at org.sonar.scanner.sensor.ModuleSensorsExecutor.lambda$execute$1(ModuleSensorsExecutor.java:48)
2023-10-10T09:51:05.7450902Z at org.sonar.scanner.sensor.ModuleSensorsExecutor$$Lambda$1252/0x00007f9d5c875720.run(Unknown Source)
2023-10-10T09:51:05.7454942Z ##[error]at org.sonar.scanner.sensor.ModuleSensorsExecutor.withModuleStrategy(ModuleSensorsExecutor.java:66)
at org.sonar.scanner.sensor.ModuleSensorsExecutor.execute(ModuleSensorsExecutor.java:48)
at org.sonar.scanner.scan.ModuleScanContainer.doAfterStart(ModuleScanContainer.java:64)
at org.sonar.core.platform.ComponentContainer.startComponents(ComponentContainer.java:123)
at org.sonar.core.platform.ComponentContainer.execute(ComponentContainer.java:109)
at org.sonar.scanner.scan.ProjectScanContainer.scan(ProjectScanContainer.java:163)
at org.sonar.scanner.scan.ProjectScanContainer.scanRecursively(ProjectScanContainer.java:159)
at org.sonar.scanner.scan.ProjectScanContainer.doAfterStart(ProjectScanContainer.java:130)
at org.sonar.core.platform.ComponentContainer.startComponents(ComponentContainer.java:123)
at org.sonar.core.platform.ComponentContainer.execute(ComponentContainer.java:109)
at org.sonar.scanner.bootstrap.ScannerContainer.doAfterStart(ScannerContainer.java:396)
at org.sonar.core.platform.ComponentContainer.startComponents(ComponentContainer.java:123)
at org.sonar.core.platform.ComponentContainer.execute(ComponentContainer.java:109)
at org.sonar.scanner.bootstrap.GlobalContainer.doAfterStart(GlobalContainer.java:128)
at org.sonar.core.platform.ComponentContainer.startComponents(ComponentContainer.java:123)
at org.sonar.core.platform.ComponentContainer.execute(ComponentContainer.java:109)
at org.sonar.batch.bootstrapper.Batch.doExecute(Batch.java:57)
at org.sonar.batch.bootstrapper.Batch.execute(Batch.java:51)
at org.sonarsource.scanner.api.internal.batch.BatchIsolatedLauncher.execute(BatchIsolatedLauncher.java:46)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
2023-10-10T09:51:05.7457244Z at org.sonar.scanner.sensor.ModuleSensorsExecutor.withModuleStrategy(ModuleSensorsExecutor.java:66)
2023-10-10T09:51:05.7457566Z at org.sonar.scanner.sensor.ModuleSensorsExecutor.execute(ModuleSensorsExecutor.java:48)
2023-10-10T09:51:05.7457855Z at org.sonar.scanner.scan.ModuleScanContainer.doAfterStart(ModuleScanContainer.java:64)
2023-10-10T09:51:05.7458158Z at org.sonar.core.platform.ComponentContainer.startComponents(ComponentContainer.java:123)
2023-10-10T09:51:05.7458454Z at org.sonar.core.platform.ComponentContainer.execute(ComponentContainer.java:109)
2023-10-10T09:51:05.7458734Z at org.sonar.scanner.scan.ProjectScanContainer.scan(ProjectScanContainer.java:163)
2023-10-10T09:51:05.7459037Z at org.sonar.scanner.scan.ProjectScanContainer.scanRecursively(ProjectScanContainer.java:159)
2023-10-10T09:51:05.7459431Z at org.sonar.scanner.scan.ProjectScanContainer.doAfterStart(ProjectScanContainer.java:130)
2023-10-10T09:51:05.7460140Z at org.sonar.core.platform.ComponentContainer.startComponents(ComponentContainer.java:123)
2023-10-10T09:51:05.7460522Z at org.sonar.core.platform.ComponentContainer.execute(ComponentContainer.java:109)
2023-10-10T09:51:05.7460819Z at org.sonar.scanner.bootstrap.ScannerContainer.doAfterStart(ScannerContainer.java:396)
2023-10-10T09:51:05.7461108Z at org.sonar.core.platform.ComponentContainer.startComponents(ComponentContainer.java:123)
2023-10-10T09:51:05.7461402Z at org.sonar.core.platform.ComponentContainer.execute(ComponentContainer.java:109)
2023-10-10T09:51:05.7461695Z at org.sonar.scanner.bootstrap.GlobalContainer.doAfterStart(GlobalContainer.java:128)
2023-10-10T09:51:05.7461983Z at org.sonar.core.platform.ComponentContainer.startComponents(ComponentContainer.java:123)
2023-10-10T09:51:05.7462281Z at org.sonar.core.platform.ComponentContainer.execute(ComponentContainer.java:109)
2023-10-10T09:51:05.7462546Z at org.sonar.batch.bootstrapper.Batch.doExecute(Batch.java:57)
2023-10-10T09:51:05.7462780Z at org.sonar.batch.bootstrapper.Batch.execute(Batch.java:51)
2023-10-10T09:51:05.7463081Z at org.sonarsource.scanner.api.internal.batch.BatchIsolatedLauncher.execute(BatchIsolatedLauncher.java:46)
2023-10-10T09:51:05.7463361Z at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
2023-10-10T09:51:06.0898375Z Process returned exit code 1
Steps to reproduce: Starting the pipeline
We had 9 projects in our solution, and it worked perfectly.
We’ve added a 10th project (AzureFunctions, C#), with about 670 lines of code, and since then we’ve been getting this error.
I’ve tried only analysing the new project, and it worked, also removing the new project, and it still works. So I’m really confused as to why it stops working with just 1 added project.
Welcome to the Sonar community, and many thanks for your feedback!
Since adding and removing this 10th project impacts the analysis outcome for some obscure reason, we might be hitting the default memory limit of the JVM here. Could you try to allocate more memory for the JVM? Here is a guide that will help you to do so.
Would it be possible to get the full logs of the analysis, ideally the verbose ones? If those contain sensitive data, just obfuscate whatever information should not be shared.
Thank you for your feedback, and welcome to our Sonar community!
Although the failure also highlights a memory issue with the JVM, the logs show it’s coming from a different analyzer, namely the Security analyzer. Therefore, at first glance, I think it’s unrelated to Edwin’s issue that originates from the JavaScript analyzer.
Please create a different thread with your report with the tags sonarcloud, csharp, and security so that the proper experts can take over and investigate your problem
We might be facing a bug triggering an infinite loop while walking the file system when looking for TSConfig files. Please try to set the property sonar.typescript.tsconfigPaths. You can provide a comma-separated list of TSConfig paths relative to your base directory.
Let’s try this workaround and see whether the problem persists or not.
It seems adding sonar.typescript.tsconfigPaths worked to prevent the loop, but now the analyses seems to analyze from a completely different path. (maybe this was the case before adding sonar.typescript.tsconfigPaths of course)
First I was getting ~2000 issues, because it was analyzing everything, including nuget packages. After adding sonar.sources=src/ and sonar.tests=tests/ that was resolved, but the paths still aren’t matching up.
Issues in SonarCloud (and in comments in Azure DevOps) now have a path starting with home/vsts/work/1/s/src/ instead of just src/.
SonarCloud also gives me a warning: SCM provider autodetection failed. Please use "sonar.scm.provider" to define SCM of your project, or disable the SCM Sensor in the project settings. This warning doesn’t seem strange if it can’t match up the paths correctly with git.
Do you know why the paths aren’t matching up anymore? How can I fix this?
The property I suggested you set for TSConfigs should not impact in any way the path issue you are now facing. I am not sure why the paths aren’t matching up anymore, unfortunately. However, I will ping SonarCloud experts so that they can assist you in that matter.
Regarding the warnings about SCM, those are just pointing out that the scanner is not able to collect data from your configured source code management like git, if any. If they are bothering you and you don’t care about them, you can just disable them with sonar.scm.disabled=true.
We try to keep it to one topic per thread. Otherwise it can get messy, fast. Would you mind creating a new thread with all your details for this question of paths?
From my perspective the solution provided by Yassin Kammoun is only a solution to a sympton that started when the paths got messed up.
Why?
Because it seems weird that I have to set the tsconfigPaths when the new project doesn’t contain any typescript. (it’s a C# Azure Function).
Looks like I’ve found the solution: the issue was with the added Azure Function project.
Because of the added Azure Function project the paths got messed up due to a bug in the SonarScanner, and that probably caused a second bug to trigger an infinite loop. Setting the sonar.typescript.tsconfigPaths solved the second bug, but not the first bug.
The solution was adding sonar.projectBaseDir=$(Agent.BuildDirectory)/s/ to the extraProperties of the pipeline task. This is a work around for the first bug, so the second bug doesn’t get triggered.
