Open olegstepanov opened 1 month ago
Thanks for the issue. This can happen if your workspace contains a lot of python files. Can you share a repro?
The workaround is what you discussed in the other issue, you set your own node executable which doesn't have a 4GB memory limit. There's more information here: https://github.com/microsoft/pylance-release/blob/main/TROUBLESHOOTING.md#pylance-is-crashing
Additionally if you turn on full logging: https://github.com/microsoft/pylance-release/blob/main/TROUBLESHOOTING.md#filing-an-issue
It should show all the files we're trying to analyze. We might get a clue as to what specifically is causing the OOM issue.
I increased the amount of memory available to Node with --max-old-space-size=8192 and it seems to be working at the moment.
Are you able to share your repository? Unless there's 10s of thousands of python files, we shouldn't be running out of memory even with 4GB. At times in the past there were some small tweaks we made that eliminated a lot of data we didn't always need to store, but it's hard to guess what that might be without a repro.
No, unfortunately I can't share the repository: the company policy denies it.
I increased memory limit to 8 Gb, but it still crashes:
<--- Last few GCs --->
[1255022:0x73283c0] 623693 ms: Mark-Compact 8073.2 (8227.9) -> 8063.8 (8235.4) MB, 5509.63 / 0.00 ms (average mu = 0.914, current mu = 0.315) allocation failure; scavenge might not succeed
[1255022:0x73283c0] 633074 ms: Mark-Compact 8079.8 (8235.4) -> 8070.5 (8241.2) MB, 9291.35 / 0.00 ms (average mu = 0.744, current mu = 0.010) allocation failure; scavenge might not succeed
<--- JS stacktrace --->
FATAL ERROR: Reached heap limit Allocation failed - JavaScript heap out of memory
----- Native stack trace -----
2024-06-16 14:06:52.449 [info] 1: 0xca5580 node::Abort() [/home/ogstepanov/.vscode-server/cli/servers/Stable-89de5a8d4d6205e5b11647eb6a74844ca23d2573/server/node]
2024-06-16 14:06:52.449 [info] 2: 0xb781f9 [/home/ogstepanov/.vscode-server/cli/servers/Stable-89de5a8d4d6205e5b11647eb6a74844ca23d2573/server/node]
2024-06-16 14:06:52.450 [info] 3: 0xeca4d0 v8::Utils::ReportOOMFailure(v8::internal::Isolate*, char const*, v8::OOMDetails const&) [/home/ogstepanov/.vscode-server/cli/servers/Stable-89de5a8d4d6205e5b11647eb6a74844ca23d2573/server/node]
2024-06-16 14:06:52.451 [info] 4: 0xeca7b7 v8::internal::V8::FatalProcessOutOfMemory(v8::internal::Isolate*, char const*, v8::OOMDetails const&) [/home/ogstepanov/.vscode-server/cli/servers/Stable-89de5a8d4d6205e5b11647eb6a74844ca23d2573/server/node]
2024-06-16 14:06:52.452 [info] 5: 0x10dc505 [/home/ogstepanov/.vscode-server/cli/servers/Stable-89de5a8d4d6205e5b11647eb6a74844ca23d2573/server/node]
2024-06-16 14:06:52.452 [info] 6: 0x10f4388 v8::internal::Heap::CollectGarbage(v8::internal::AllocationSpace, v8::internal::GarbageCollectionReason, v8::GCCallbackFlags) [/home/ogstepanov/.vscode-server/cli/servers/Stable-89de5a8d4d6205e5b11647eb6a74844ca23d2573/server/node]
2024-06-16 14:06:52.453 [info] 7: 0x10ca4a1 v8::internal::HeapAllocator::AllocateRawWithLightRetrySlowPath(int, v8::internal::AllocationType, v8::internal::AllocationOrigin, v8::internal::AllocationAlignment) [/home/ogstepanov/.vscode-server/cli/servers/Stable-89de5a8d4d6205e5b11647eb6a74844ca23d2573/server/node]
2024-06-16 14:06:52.454 [info] 8: 0x10cb635 v8::internal::HeapAllocator::AllocateRawWithRetryOrFailSlowPath(int, v8::internal::AllocationType, v8::internal::AllocationOrigin, v8::internal::AllocationAlignment) [/home/ogstepanov/.vscode-server/cli/servers/Stable-89de5a8d4d6205e5b11647eb6a74844ca23d2573/server/node]
2024-06-16 14:06:52.455 [info] 9: 0x10a8c86 v8::internal::Factory::NewFillerObject(int, v8::internal::AllocationAlignment, v8::internal::AllocationType, v8::internal::AllocationOrigin) [/home/ogstepanov/.vscode-server/cli/servers/Stable-89de5a8d4d6205e5b11647eb6a74844ca23d2573/server/node]
2024-06-16 14:06:52.460 [info] 10: 0x1503a16 v8::internal::Runtime_AllocateInYoungGeneration(int, unsigned long*, v8::internal::Isolate*) [/home/ogstepanov/.vscode-server/cli/servers/Stable-89de5a8d4d6205e5b11647eb6a74844ca23d2573/server/node]
11: 0x7f8949e99ef6
2024-06-16 14:06:53.377 [info] [Error - 2:06:53 PM] Server process exited with signal SIGABRT.
Unfortunately I cannot provide neither snapshots of my workspace nor filenames, etc.
But if there were a way to provide high-level stats such as number of files/lines pylance is trying to index, distribution of file sizes and amount of time needed to index them, I could send that. Also, if I could see hottest directories/files locally, I could decide whether I could exclude them from indexing.
So far I couldn't find a good way to get this data from workspace configuration.
Yeah we need to take a heap snapshot to figure out where the problem is. But without a repro taking a heap snapshot on a release build will mangle all of the types, making it all but impossible to figure out where the problem is.
I don't think it's the number of files though. I can open the root of my C: drive and pylance continues to work just fine. It's 100s of thousands of files.
I'm guessing it doesn't immediately crash either, making it hard for you to narrow down the problem.
Can you share your requirements.txt at least? I can try reproing with the same venv at least.
if you think it is related to indexing, you can set "python.analysis.indexing": false
and see whether OOM stops.
Environment data
Log