Svelte LSP crashes due to out of memory #2738
Comments
|
By the way, after the server crashes, it restarts, reserves all possible memory and crashes again. The laptop is like a stove |
To clarify, is this the correct number? 13k project files, i.e. stuff in your
I assume you mean 109.5.2?
To clarify, the crash already happens on version 109.5.3, i.e. 109.5.2 is the last one that works? 109.5.3 bumps TypeScript to version 5.8, wondering if that has something to do with it. |
I assume that LSP is based on ./tsconfig.json. 13k files inside included dirs // ./tsconfig.json
{
"extends": "./.svelte-kit/tsconfig.json",
"compilerOptions": {
"moduleResolution": "bundler",
"module": "es2022",
"lib": ["es2021", "dom"],
"target": "es2022",
},
"include": [
"src/**/*.d.ts",
"src/**/*.js",
"src/**/*.ts",
"src/**/*.svelte",
"infra/**/*.ts",
"tests/**/*.ts",
".storybook/**/*.ts",
"scripts/swagger/features.swagger.ts"
],
"exclude": ["src/**/*.stories.svelte"]
}
// .svelte-kit/tsconfig.json
{
"include": [
"ambient.d.ts",
"non-ambient.d.ts",
"./types/**/$types.d.ts",
"../vite.config.js",
"../vite.config.ts",
"../src/**/*.js",
"../src/**/*.ts",
"../src/**/*.svelte",
"../tests/**/*.js",
"../tests/**/*.ts",
"../tests/**/*.svelte"
],
"exclude": [
"../node_modules/**",
"../src/service-worker.js",
"../src/service-worker/**/*.js",
"../src/service-worker.ts",
"../src/service-worker/**/*.ts",
"../src/service-worker.d.ts",
"../src/service-worker/**/*.d.ts"
]
} |
No. There are no problems with version 108.5.2. We have not tested all versions, we found this one using empirical method. |
It is safe to say that after 108.5.2 there are versions on which the problem is reproduced. Definitely on the latest version (109.5.4) it is reproduced |
|
Is this the same project as #2329? I am really curious about what exactly this project is about when you can create 5000 more source files in a year. Are there a lot of generated files? #2725 is another recent out-of-memory report, but it seems like it is because the library-generated schema type is way too complicated. Have you used any similar library? |
So you are actually refering to https://github.com/sveltejs/language-tools/releases/tag/extensions-108.5.2 which was realeased more than 6 months ago? Why did the error only occur now then? What has changed recently in your project to may have caused this? |
Yes, it's the same project. The project has been alive and developing for 4 years now. A lot of code. |
I guess it's related to svelte 5 support. In my free time I will try other versions of the extension to find out exactly which one is causing the problem. |
|
Hi, I checked the versions and found the one with which the problem starts 109.0 - ok 109.5.2 - ok 109.5.3 - fail 109.5.4 - fail |
|
A few notes:
|
To clarify: Do you really have 13k files in your Also very strange that according to the logs you have 0 files included from node_modules.
https://github.com/sveltejs/language-tools/releases/tag/extensions-109.5.3 is the list of changes. From a quick look only the TypeScript version bump stands out. Could you test if that version bump is the culprit? In order to test it, go into the folder where your VS Code extension is installed, in there go into |
|
Here are the statistics for directories |
|
I changed the package version to 5.7, it didn't help. I added the "MODDED" log to the extension Proof: > pwd
# output
/Users/mrwaip/.vscode/extensions/svelte.svelte-vscode-109.5.3
> cat ./node_modules/typescript/package.json | grep version
# output
"version": "5.7.3",For help, see: https://nodejs.org/en/docs/inspector
MODDED!!!!!!!!!
Initialize language server at file:///Users/mrwaip/code/project
Initialize new ts service at /Users/mrwaip/code/project/tsconfig.json
Trying to load configs for /Users/mrwaip/code/project
Loaded config at /Users/mrwaip/code/project/svelte.config.js
SnapshotManager File Statistics:
Project files: 13401
Svelte files: 3719
From node_modules: 0
Total: 13401
SnapshotManager File Statistics:
Project files: 13401
Svelte files: 3719
From node_modules: 2938
Total: 16647
<--- Last few GCs --->
[91496:0x11800310000] 94970 ms: Mark-Compact 4063.9 (4078.8) -> 4060.2 (4079.3) MB, pooled: 0 MB, 677.38 / 0.00 ms (average mu = 0.066, current mu = 0.031) allocation failure; scavenge might not succeed
[91496:0x11800310000] 95667 ms: Mark-Compact 4064.3 (4079.3) -> 4060.7 (4079.8) MB, pooled: 0 MB, 683.67 / 0.00 ms (average mu = 0.043, current mu = 0.019) allocation failure; scavenge might not succeed
<--- JS stacktrace --->
FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory
----- Native stack trace -----
1: 0x1143440bc node::OnFatalError(char const*, char const*) [/Applications/Visual Studio Code.app/Contents/Frameworks/Electron Framework.framework/Versions/A/Electron Framework]
2: 0x10e79eaf4 node::GetEnvironmentIsolateData(node::Environment*) [/Applications/Visual Studio Code.app/Contents/Frameworks/Electron Framework.framework/Versions/A/Electron Framework]
3: 0x10e79ea88 node::GetEnvironmentIsolateData(node::Environment*) [/Applications/Visual Studio Code.app/Contents/Frameworks/Electron Framework.framework/Versions/A/Electron Framework]
4: 0x10e9779b0 fontations_ffi$cxxbridge1$has_any_color_table [/Applications/Visual Studio Code.app/Contents/Frameworks/Electron Framework.framework/Versions/A/Electron Framework]
5: 0x10e98d534 v8::internal::StrongRootAllocatorBase::deallocate_impl(unsigned long*, unsigned long) [/Applications/Visual Studio Code.app/Contents/Frameworks/Electron Framework.framework/Versions/A/Electron Framework]
6: 0x10e98cfac v8::internal::StrongRootAllocatorBase::deallocate_impl(unsigned long*, unsigned long) [/Applications/Visual Studio Code.app/Contents/Frameworks/Electron Framework.framework/Versions/A/Electron Framework]
7: 0x10f1c4018 cppgc::internal::AgeTable::ResetForTesting() [/Applications/Visual Studio Code.app/Contents/Frameworks/Electron Framework.framework/Versions/A/Electron Framework]
8: 0x10e9752e4 fontations_ffi$cxxbridge1$has_any_color_table [/Applications/Visual Studio Code.app/Contents/Frameworks/Electron Framework.framework/Versions/A/Electron Framework]
9: 0x10e96b260 fontations_ffi$cxxbridge1$has_any_color_table [/Applications/Visual Studio Code.app/Contents/Frameworks/Electron Framework.framework/Versions/A/Electron Framework]
10: 0x10e94a0e8 fontations_ffi$cxxbridge1$has_any_color_table [/Applications/Visual Studio Code.app/Contents/Frameworks/Electron Framework.framework/Versions/A/Electron Framework]
11: 0x10d53c448 uv_get_osfhandle [/Applications/Visual Studio Code.app/Contents/Frameworks/Electron Framework.framework/Versions/A/Electron Framework]
12: 0x10ee139d8 v8::internal::TickSample::print() const [/Applications/Visual Studio Code.app/Contents/Frameworks/Electron Framework.framework/Versions/A/Electron Framework]
13: 0x177eafa74
14: 0x177f37f1c
15: 0x177e9bc84
16: 0x1701470d4
17: 0x170f2dca0
18: 0x17016e54c
19: 0x1704a3478
20: 0x170f40fc0
21: 0x170fb68fc
22: 0x170170808
23: 0x170fb16e8
24: 0x170cc6ba8
25: 0x1704438b0
26: 0x170462138
27: 0x177e0d624
28: 0x177e0d624
29: 0x177e0d624
30: 0x177e0d624
31: 0x177e0d624
32: 0x177e0d624
33: 0x177e0d624
34: 0x177e4de28
35: 0x177f26a18
36: 0x177e3ca9c
37: 0x177e0b0f4
38: 0x10e8ce5a0 v8::Unwinder::PCIsInV8(unsigned long, v8::MemoryRange const*, void*) [/Applications/Visual Studio Code.app/Contents/Frameworks/Electron Framework.framework/Versions/A/Electron Framework]
39: 0x10e8cf334 v8::Unwinder::PCIsInV8(unsigned long, v8::MemoryRange const*, void*) [/Applications/Visual Studio Code.app/Contents/Frameworks/Electron Framework.framework/Versions/A/Electron Framework]
40: 0x10e8cf488 v8::Unwinder::PCIsInV8(unsigned long, v8::MemoryRange const*, void*) [/Applications/Visual Studio Code.app/Contents/Frameworks/Electron Framework.framework/Versions/A/Electron Framework]
41: 0x10e8fcff0 v8::Unwinder::PCIsInV8(unsigned long, v8::MemoryRange const*, void*) [/Applications/Visual Studio Code.app/Contents/Frameworks/Electron Framework.framework/Versions/A/Electron Framework]
42: 0x114278a04 node::CallbackScope::~CallbackScope() [/Applications/Visual Studio Code.app/Contents/Frameworks/Electron Framework.framework/Versions/A/Electron Framework]
43: 0x1142786cc node::CallbackScope::~CallbackScope() [/Applications/Visual Studio Code.app/Contents/Frameworks/Electron Framework.framework/Versions/A/Electron Framework]
44: 0x11434bf60 node::OnFatalError(char const*, char const*) [/Applications/Visual Studio Code.app/Contents/Frameworks/Electron Framework.framework/Versions/A/Electron Framework]
45: 0x11435f3b8 fontations_ffi$cxxbridge1$BridgeOutlineCollection$operator$sizeof [/Applications/Visual Studio Code.app/Contents/Frameworks/Electron Framework.framework/Versions/A/Electron Framework]
46: 0x11433d8fc node::Buffer::New(v8::Isolate*, char*, unsigned long) [/Applications/Visual Studio Code.app/Contents/Frameworks/Electron Framework.framework/Versions/A/Electron Framework]
47: 0x10d58483c uv_barrier_destroy [/Applications/Visual Studio Code.app/Contents/Frameworks/Electron Framework.framework/Versions/A/Electron Framework]
48: 0x10d587ebc uv_async_send [/Applications/Visual Studio Code.app/Contents/Frameworks/Electron Framework.framework/Versions/A/Electron Framework]
49: 0x10d59898c uv_free_interface_addresses [/Applications/Visual Studio Code.app/Contents/Frameworks/Electron Framework.framework/Versions/A/Electron Framework]
50: 0x10d588388 uv_run [/Applications/Visual Studio Code.app/Contents/Frameworks/Electron Framework.framework/Versions/A/Electron Framework]
51: 0x1142796b8 node::MakeCallback(v8::Isolate*, v8::Local<v8::Object>, v8::Local<v8::Function>, int, v8::Local<v8::Value>*) [/Applications/Visual Studio Code.app/Contents/Frameworks/Electron Framework.framework/Versions/A/Electron Framework]
52: 0x11427a558 node::SpinEventLoop(node::Environment*) [/Applications/Visual Studio Code.app/Contents/Frameworks/Electron Framework.framework/Versions/A/Electron Framework]
53: 0x10d59d084 v8::ValueSerializer::Delegate::HasCustomHostObject(v8::Isolate*) [/Applications/Visual Studio Code.app/Contents/Frameworks/Electron Framework.framework/Versions/A/Electron Framework]
54: 0x10d5991c8 ElectronInitializeICUandStartNode [/Applications/Visual Studio Code.app/Contents/Frameworks/Electron Framework.framework/Versions/A/Electron Framework]
55: 0x19433eb4c start [/usr/lib/dyld]
[Error - 09:38:17] Server process exited with signal SIGABRT.
[Info - 09:38:17] Connection to server got closed. Server will restart.
true
Debugger listening on ws://127.0.0.1:9229/040d6fb7-5de1-4f1b-81e3-77d3e230087e
For help, see: https://nodejs.org/en/docs/inspector
MODDED!!!!!!!!!
Initialize language server at file:///Users/mrwaip/code/project
Initialize new ts service at /Users/mrwaip/code/project/tsconfig.json
Trying to load configs for /Users/mrwaip/code/project
Loaded config at /Users/mrwaip/code/project/svelte.config.js
SnapshotManager File Statistics:
Project files: 13401
Svelte files: 3719
From node_modules: 0
Total: 13401 |
|
Can you try this to see if you can increase the memory limit above 4GB? #2725 (comment). |
|
@jasonlyu123 any idea which change in https://github.com/sveltejs/language-tools/releases/tag/extensions-109.5.3 could've caused this? My guess would be #2635 or #2676 (for reasons unknown to me) because I can't see anything else affecting this. |
Could it be #2668 since it needs to check the snippets over and over until they are stable? |
I don't know. Taking a snapshot took about 10 minutes and ate up all my RAM. 
|
|
Here is a snapshot after a couple of minutes Sorry but I can't compare them because they weigh about 7GB each and just don't fit into the PC's memory |
|
Are these screenshots taken from 109.5.2 and 109.5.4, respectively, both with the From this Electron documentation, the reason for the 4GB limit is pointer compression, which also reduces the memory by up to 40%. If you were using 6.2GB of memory without pointer compression, then in the best case, it is 3.7GB with pointer compression. It's already very close to the 4GB limit. Maybe that meant the problem is just somehow the memory usage is increased a bit from 109.5.2 to 109.5.3? |
|
Nope. Both screenshots from 109.5.3 |
|
Oh. I misunderstood what you meant. Can you take the same screenshot of 109.5.2 with the |
|
Sorry. I don't quite understand what needs to be done to help you. Do you want me to compare snapshots from 100.5.2 and 109.5.3? |
|
Also yes, I redefined runntime path in config to locally installed nosejs version 22, but lsp still crashes |
Weird, if it still crashes, how do you record the heap snapshot? What I want to know is if increasing the memory limit stops the crash. If it does stop the crash, I want to know the difference in memory usage between 109.5.2 and 109.5.3. The difference between the total heap usage and the kinds of objects that take up most memory. I don't need the comparison using the diff tool in Chrome Dev Tools. |
|
Inside debugger I stop the code. Also I assume while snapshotting code is freezed |
I'll try, but later |
In version 109.5.2 after full initialization (for example goto works in svelte files) taking a snapshot took much less time |
Did you set a breakpoint? If so, where is the breakpoint? Or the language server is stuck in loading, and you just stop it without knowing where it actually stops? If it is the latter, it does sound like there might be an infinite loop. |
Compared the versions 109.5.2 and 109.5.3. Here is the result Snapshot 1 - 109.5.2 |
I waited a few minutes before it overflow and pause process 
|
|
Oh. If it is paused, did the debugger show where it stopped? Sorry for the long conversation, I kind of have remote debugging since I can't reproduce the issue. If you're in the Svelte Discord, you could open a thread in the https://discord.com/channels/457912077277855764/689494103380983930. Messaging in a discord thread might be better than constantly pinging other people on this issue. |
I think it's high time you started some kind of benchmark project for such things) |
Sorry for the long reply, execution stopped somewhere inside Nodejs while processing tasks |
I waited until more memory was allocated and paused the process in the debugger. I tried jumping around the breakpoints, and was always inside the file parsing. I conclude that something makes Typescript scan the project endlessly. This is confirmed even by snapshots, because the sources in memory grow the most Maybe here : |
|
@dummdidumm hi, any great ideas? Need more debug? |
|
Update from my side, another user in the Svelte Discord is experiencing a similar issue with a project far smaller, so the project size is likely not the problem. Judging from the CPU profile they provided and what you find, the problem seems to be that something keeps triggering file updates, so the typescript kept having to rebuild the program. Or some cache is not being used correctly, so it has to start over again. But I still can't figure out what caused the problem. At this point, I don't think there is much I can do unless there is a reproduction. Their project is far smaller, so maybe it's more possible for them to narrow down the problem for a reproduction. |
|
I am not sure if I can be of much help, as I am not terribly experienced with Svelte, however, I have a small project I started on Friday. Even having resolved all typing errors/etc, I am running into this. I have a much larger project configured nearly identical which doesn't have the issues but is operating with the node adapter. I am not terribly concerned about resolving it for myself, but if the project would be helpful for inspection, I can mark the repo public. |
If you can make the small project public that would be super helpful |
|
Here it is, sorry that was slow... Interestingly, I don't think I'm having issues with the server anymore. I didn't really do many commits today, and there were a lot of changes in-between, but I did copy much of my tsconfig.json and I think I changed some things in package.json to match my other project which was not having the issues. Busy day, and it's been on the side, so I'm sorry I can't be more specific. I can say, it seems to run okay for a while before it would hang up, and it always seemed sluggish compared to my other project which is huge by comparison. I hope this helps - let me know if you have any questions. |
|
109.6.0 has reduced memory usage in larger projects. Can you check if that prevents the crash for you? |
|
I launched lsp 109.6.0 on my project and it stopped crashing. The memory took up 1.82 - 1.5 GB. Thank you very much for investigating the problem |
|
Great to hear! I'll close this then, feel free to open a new issue if this comes up again or ping in this one |
Describe the bug
Hi!
At my work in our monolithic project the svelte extension started to crash on startup. This doesn't happen on version 108.5.2, so we locked it. In fact, VS Code turns into a primitive text editor.
I just checked, the problem is reproduced on version 109.5.4.
The project uses Svelte 4.2.18
Reproduction
IDK. Big codebase.
Expected behaviour
LSP doesn't crash
System Info
Which package is the issue about?
svelte-language-server
Additional Information, eg. Screenshots
Vs Code config:
{ "typescript.tsserver.maxTsServerMemory": 8192, "svelte.language-server.runtime-args": ["--max-old-space-size=8192"] }The text was updated successfully, but these errors were encountered: