Programming language you’re coding in: C#, typescript
Is connected mode used: Cannot connect
SonarQube Cloud, SonarQube Server, or SonarQube Community Build? (if one of the latter two, which version?):
And a thorough description of the problem / question:
I am running VS code in WSL/Ubuntu. When I try to connect to the SonarQube Cloud, I cannot. The “Generate Token” button does not work. When I create a token in the SonarQube website and paste it in, nothing happens. No organization appears in the “Organization” dropdown.
A few minutes after opening VS code, in the SonarQube for IDE output, I receive the following error:
2025-07-31 14:05:41.460 [info] [Info - 14:05:41.402] [sonarlint : SonarLint Server RPC sequential executor] Started embedded server on port 64120
2025-07-31 14:08:22.902 [info] [Error - 14:08:22.900] [org.eclipse.lsp4j.jsonrpc.json.ConcurrentMessageProcessor : Server message reader] java.io.IOException: Pipe broken
2025-07-31 14:08:22.902 [info] [Error - 14:08:22.900] [org.eclipse.lsp4j.jsonrpc.json.ConcurrentMessageProcessor : Server message reader] org.eclipse.lsp4j.jsonrpc.JsonRpcException: java.io.IOException: Pipe broken
at org.eclipse.lsp4j.jsonrpc.json.StreamMessageProducer.listen(StreamMessageProducer.java:125)
at org.eclipse.lsp4j.jsonrpc.json.ConcurrentMessageProcessor.run(ConcurrentMessageProcessor.java:114)
at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source)
at java.base/java.util.concurrent.FutureTask.run(Unknown Source)
at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.base/java.lang.Thread.run(Unknown Source)
Caused by: java.io.IOException: Pipe broken
at java.base/java.io.PipedInputStream.read(Unknown Source)
at org.eclipse.lsp4j.jsonrpc.json.StreamMessageProducer.listen(StreamMessageProducer.java:82)
... 6 common frames omitted
I have solved the issue; this is the set of steps I went through.
I enabled debug logs and analytics, as you requested.
Once I did that, I noticed that an OutOfMemoryError is thrown.
I checked the memory allocation using top and found that my PC had only allocated 16 GB to WSL, and not much memory was left.
I increased the memory allocation of WSL in .wslconfig to be 20 GB.
A different error occurred, telling me that the Java Heap was running out of memory.
I therefore increased the max heap size to be 8 GB.
Once I did that, the extension was able to load successfully.
This is not an overly large project. Therefore, I’m puzzled about why this project needs adjustments of the memory settings for both the WSL Ubuntu Virtual Machine, and the Java Virtual machine, so that it can load successfully.
Thank you for sharing your solution! It’s great to hear you were able to resolve the issue. Your steps are very helpful for others who might encounter a similar problem.
Regarding your question about why the project required such a significant memory allocation, it’s a valid point. There are a few things to consider, and a few more questions that could help us understand the situation better:
Could you tell us whether this started happening after a recent SonarQube for IDE update?
It’s worth noting that C# analysis, which you’re performing, can be particularly demanding on resources due to the reliance on Omnisharp.
In general, the memory usage is highly dependent on a variety of factors, including the project size, the languages involved, and what other processes are also running within your WSL environment. It can be difficult to pinpoint the exact reason why this particular project required 20GB of memory, but your solution was the correct way to handle it.
This happened when I tried to connect to SonarQube Cloud for the first time in VS code.
Yes, I am running VS code in WSL. I am following the official Microsoft guide.
Does SonarQube analyze the files in the cdk.out directory, which is the output of a cdk diff command? This directory had quite a few files. Could this have contributed to the large amount of memory required?
thanks for the extra info. It sounds like you’re doing everything right. Your suspicions about the cdk.out directory is spot on.
First, you’re right, the extension does analyze files in cdk.out, and this is a known issue that can affect performance. It’s a small part of the problem, but it definitely contributes to the high memory usage.
I ran some experiments and the biggest factor, though, is the project’s location. When you run VS Code in WSL, everything is happening in a Linux environment. If your project is on the Windows filesystem (e.g., under /mnt/c/Users/<username>/.../project), the extension has to constantly cross a bridge between the Linux and Windows filesystems to access the files. This is a very slow process.
If the above is true for your case, the best solution is to move your project to the native WSL filesystem. Try cloning, copying or moving your project to a path like /home/<username>/.../project. When you open the project from that location, the file access will be much faster and should as well solve the memory issues you’re seeing.