Volar crashes quickly using VS Code remote containers on Docker #514
Comments
|
I have similar Problem !!! Logs in Volar - API[Error - 4:27:43 PM] Request textDocument/codeAction failed.
Message: Request textDocument/codeAction failed with message: Cannot read property 'lastIndexOf' of undefined
Code: -32603
[Error - 4:27:43 PM] Request textDocument/codeAction failed.
Message: Request textDocument/codeAction failed with message: Cannot read property 'lastIndexOf' of undefined
Code: -32603 |
Error on VsCode@1.60.1But no error on VsCode@1.59.1 |
Thanks for this, I was sure the bug happened after some update, but didn't know which piece of software. EDIT: I still have crashes after using VS Code 1.59.1 |
|
I think @2256184693 has different problem. @ddahan can you reproduce this problem without docker? |
|
My error is because of my own wrong in |
@2256184693 how did you solve it? |
Unfortunately I can't try without Docker. This is very annoying because as soon as it crashed, everything is broken and the only workaround is to restart Docker, close and reopen the project in VS Code. |
|
I think this problem is specific to docker, and almost no people use volar in docker. :S |
To be more specific, I'm using VS Code dev containers: https://code.visualstudio.com/docs/remote/containers
It could, but there no evidence here :/ But since the crash happens after some time, this is very hard to debug by testing all versions of everything. EDITI do not need to restart Docker to make it work again, just closing the connection to remote server in vs code. |
|
How long does crashes happen usually? |
Not always the same, but the crashes after a Volar action indeed. If i Do nothing it won't crash. And after this, I need to disconect/reconnect vs code remote connection to stop the error flow. |
|
@ddahan From where are you getting these logs? I have similar behavior.
I'm also in docker with dev containers and I think it's a pretty common setup these days. The behavior I'm getting is 100% cpu usage until the container becomes unresponsive and all I can do is restart vscode. It happens either on certain intellisense lookups (maybe failed lookups, where it can't find the types) or when I'm trying to save a file. Especially on the file save action. |
You can get the logs in the
Thanks, I had the same suspicion, because Volar errors seem to appear at the same moment that my container is unstable and slow. |
|
@ddahan Thanks. That is where I was looking for the logs, but couldn't find anything similar to yours. The only thing that points me to volar is a popup is lower right corner from VSCode saying it's waiting for Volar. I'll keep an eye on it. |
I think your message is that Volar is waiting, so it's not crashing. And as long as you have no crash, there is no Volar section in the right menu, makes sense. |
|
It crashes eventually: Sometimes I get a similar thing from Eslint as well: Maybe there's a conflict between the two. |
|
I think you can open a issue to https://github.com/microsoft/vscode-remote-release/issues, should have more chance of getting some enlightenment. |
|
I think I've sorted the issue on my side. I have 2 days without crashes so far, and it used to happen multiple times during the day.
The Because I have 2 VSCode instanced attached to containers all the time and a couple of servers running, the memory usage on WSL when doing nothing is around 4.2 GB ( @ddahan See if increasing these values fixes it for you as well. I think each Vscode instance takes about 1.5 GB. |
|
@ovidiuc Thanks for sharing your solution! I know it can be a convenient workaround, but I'm not huge fan of raising memory limits of everything just to fix a little piece of my workflow that crashes. Because it's not supposed to crash even if there is not enough memory. My current solution is to use Vetur instead of Volar, and deactivate experimental template interpolation (that does not work very well, unlike Volar). I'm losing features, but I have 0 crash, without config twistings. |
|
If memory usage is the problem, you can setting |
|
@ddahan WSL is Windows Subsystem for Linux. If you don't have it, no configuration needed. Glad you've found a "solution". But yeah, I agree with you, it should not crash. @johnsoncodehk Thanks, the setting didn't have much effect. Maybe the problem is not that Volar is using too much memory, but that when the system runs out of memory, Volar doesn't know what to do. Or node, or docker, or eslint. Have no idea which is to blame here, have no experience in extension building. Too many variables and when the container becomes unresponsive, you have no way to run commands on it and see what's going on. |
|
Hi guys, I'm almost sure the problem is solved now 👍🏻 As you may know, there are two main ways to open a remote dev container in VS code:
I was using the first solution, and recently noticed that all performances issues were related to this mode, because of obvious I/O throttling, due to the need to permanently synchronise the local and remote folders together. More on remote container performance improvement here. |
ddahan
changed the title
|
@ddahan good to know! But this does not seem to explain why vetur works but volar does not. 🤔 |
|
For me, everything "worked" except Volar. But when I mean "work", I mean "does not crash". I had other extensions which froze, but no crash. Maybe you could stress test Volar to try to reproduce the issue and investigate further, even I'm not sure this is priority. |
|
@ovidiuc - Your suggested fix worked for me too. (for Quasar). Thanks! Scott |
|
|
I get this error on the project I'm working on without Docker or anything remote |
|
We are experiencing the same error without Docker - but while using Live Share instead (to collaborate together for pair coding sessions). Any ideas or pointers at least at what we should look? We are all on MacOS and without any docker instances. The repo is indeed a monorepo, but a very small one (recently created with only handful of components shared across 2 apps). Really appreciate any help or ideas! |
|
I'm also getting this
|
|
Same here. |
|
same problem on code-server v.4.5.1 (vscode 1.68.1) vue3 + vite |
|
I have been seeing this, its just running out of memory, see this screenshot each "sawtooth" is Volar crashing:
Doubling the available memory seems to fix it:
|
|
@samwillis thanks for the information! Could you try v1.0.0-beta.0 and check does it reduces memory usage? |
|
@johnsoncodehk I have given that a go. For anyone else testing you have to follow these instructions to install in the remote VM/Container: https://github.com/microsoft/vscode-jupyter/wiki/How-to-install-from-VSIX-on-VS-Code-when-using-Remote-SSH Unfortunately not seeing any reduction in memory usage, the drop and then ramp up in the graph is when I installed and reloaded:
I have killed it and restarted a couple of time to check. |
|
@samwillis I found that template codegen may take a lot of memory usage, could you try setting |
|
@johnsoncodehk I fought with performance issues for a long time and finally found this thread and especially your response. Before, I could not even really work because it was sooo slow but it seems that this was they key 😊 Does it come with any downsides? I noticed that I cannot click anything within the templates so I assume it's related to that? |
|
Do you mean enabling skipTemplateCodegen solves your project's slow performance? Anyway please open a new issue to avoid discussion on unrelated issues. |
Description
I'm using Volar extension is a TS/Vue project, in a devcontainer on VS Code.
When building the container, everything works as expected, but at some point in the time (I can't determine when exactly), the volar extension crashes. This means the extension does not work as expected and I keep getting lots of error for anything.
Here is part of the content of the logs in vs code:
Volar - Document
Volar - API
Bug Reproduction:
To be honest, I don't know how to reproduce it, it seems unpredictable. The only things I'm sure is that it does occur after some time, because at the beginning everything is fine.
Versions:
The text was updated successfully, but these errors were encountered: