Crash of all vscode extensions on codebase index generation

[BasileLTC]

Description

I have experienced loop crashed of all vscode extensions when trying to index very large codebases through kilocode. Indexing was still working a day before with the same codebase !

KiloCode version: v4.64.0 VSCode version :

Version: 1.102.1
Commit: 7adae6a56e34cb64d08899664b814cf620465925
Date: 2025-07-15T16:41:17.147Z (1 wk ago)
Electron: 35.6.0
ElectronBuildId: 11847422
Chromium: 134.0.6998.205
Node.js: 22.15.1
V8: 13.4.114.21-electron.0
OS: Darwin arm64 24.5.0

Here is my console log :

 WARN [mainThreadStorage] large extension state detected (extensionId: kilocode.kilo-code, global: true): 1383.5830078125kb. Consider to use 'storageUri' or 'globalStorageUri' to store this data on disk instead.
warn @ log.ts:450
warn @ log.ts:559
warn @ logService.ts:47
getExtensionStateRaw @ extensionStorage.ts:164
(anonymous) @ mainThreadStorage.ts:34
C @ event.ts:1219
fire @ event.ts:1250
(anonymous) @ event.ts:165
C @ event.ts:1219
D @ event.ts:1230
fire @ event.ts:1254
resume @ event.ts:1406
y @ storage.ts:501
store @ storage.ts:467
setExtensionState @ extensionStorage.ts:175
$setValue @ mainThreadStorage.ts:57
S @ rpcProtocol.ts:458
Q @ rpcProtocol.ts:443
M @ rpcProtocol.ts:373
L @ rpcProtocol.ts:299
(anonymous) @ rpcProtocol.ts:161
C @ event.ts:1219
fire @ event.ts:1250
fire @ ipc.net.ts:652
l.onmessage @ localProcessExtensionHost.ts:382

## Fatal process out of memory: Zone#----- Native stack trace ----- 1: 0x1109b2acc node::WorkerThreadsTaskRunner::DelayedTaskScheduler::RunTask(uv_timer_s*) [/Applications/Visual Studio Code.app/Contents/Frameworks/Electron Framework.framework/Versions/A/Electron Framework] 2: 0x113ba10c4 ares_llist_node_next [/Applications/Visual Studio Code.app/Contents/Frameworks/Electron Framework.framework/Versions/A/Electron Framework] 3: 0x1116d91dc v8::CpuProfileNode::GetNodeId() const [/Applications/Visual Studio Code.app/Contents/Frameworks/Electron Framework.framework/Versions/A/Electron Framework] 4: 0x10e4a7478 v8::Function::GetName() const [/Applications/Visual Studio Code.app/Contents/Frameworks/Electron Framework.framework/Versions/A/Electron Framework] 5: 0x10ee2a5f4 v8::Object::New(v8::Isolate*) [/Applications/Visual Studio Code.app/Contents/Frameworks/Electron Framework.framework/Versions/A/Electron Framework] 6: 0x10f319c44 v8::internal::compiler::CompilationDependencies::DependOnInitialMapInstanceSizePrediction(v8::internal::compiler::JSFunctionRef) [/Applications/Visual Studio Code.app/Contents/Frameworks/Electron Framework.framework/Versions/A/Electron Framework] 7: 0x10f319800 v8::internal::compiler::CompilationDependencies::DependOnInitialMapInstanceSizePrediction(v8::internal::compiler::JSFunctionRef) [/Applications/Visual Studio Code.app/Contents/Frameworks/Electron Framework.framework/Versions/A/Electron Framework] 8: 0x10f3165d0 v8::internal::compiler::CompilationDependencies::DependOnInitialMapInstanceSizePrediction(v8::internal::compiler::JSFunctionRef) [/Applications/Visual Studio Code.app/Contents/Frameworks/Electron Framework.framework/Versions/A/Electron Framework] 9: 0x10f3162d4 v8::internal::compiler::CompilationDependencies::DependOnInitialMapInstanceSizePrediction(v8::internal::compiler::JSFunctionRef) [/Applications/Visual Studio Code.app/Contents/Frameworks/Electron Framework.framework/Versions/A/Electron Framework]10: 0x10e805b50 v8::internal::compiler::CompilationDependencies::DependOnStableMap(v8::internal::compiler::MapRef) [/Applications/Visual Studio Code.app/Contents/Frameworks/Electron Framework.framework/Versions/A/Electron Framework]11: 0x10e805944 v8::internal::compiler::CompilationDependencies::DependOnStableMap(v8::internal::compiler::MapRef) [/Applications/Visual Studio Code.app/Contents/Frameworks/Electron Framework.framework/Versions/A/Electron Framework]12: 0x10fed22dc v8::metrics::Recorder::GetContext(v8::Isolate*, v8::metrics::Recorder::ContextId) [/Applications/Visual Studio Code.app/Contents/Frameworks/Electron Framework.framework/Versions/A/Electron Framework]13: 0x10fed10f0 v8::metrics::Recorder::GetContext(v8::Isolate*, v8::metrics::Recorder::ContextId) [/Applications/Visual Studio Code.app/Contents/Frameworks/Electron Framework.framework/Versions/A/Electron Framework]14: 0x10fed0b38 v8::metrics::Recorder::GetContext(v8::Isolate*, v8::metrics::Recorder::ContextId) [/Applications/Visual Studio Code.app/Contents/Frameworks/Electron Framework.framework/Versions/A/Electron Framework]15: 0x111a95af4 v8::internal::Version::GetSONAME(v8::base::Vector<char>) [/Applications/Visual Studio Code.app/Contents/Frameworks/Electron Framework.framework/Versions/A/Electron Framework]16: 0x111a95438 v8::internal::Version::GetSONAME(v8::base::Vector<char>) [/Applications/Visual Studio Code.app/Contents/Frameworks/Electron Framework.framework/Versions/A/Electron Framework]17: 0x113ba4a78 ares_llist_node_next [/Applications/Visual Studio Code.app/Contents/Frameworks/Electron Framework.framework/Versions/A/Electron Framework]18: 0x1109affa8 node::WorkerThreadsTaskRunner::WorkerThreadsTaskRunner(int) [/Applications/Visual Studio Code.app/Contents/Frameworks/Electron Framework.framework/Versions/A/Electron Framework]19: 0x19331ac0c _pthread_start [/usr/lib/system/libsystem_pthread.dylib]20: 0x193315b80 thread_start [/usr/lib/system/libsystem_pthread.dylib]

I'm using qdrant locally through docker with enough space and ram, and voyage 3-large.

[craigvc]

Confirmed same think crashes extension when indexing via ollama and local qdrant

[DexterHuang]

confirm happens, ollama and remote qdrant turn off index to fix it for now

[Enrique-Leal-Sierra]

confirm same on gemini, both in cursor and in vscode. tried remote & local qdrant

[devlux76]

One issue seems to be how hard it's hitting ollama. ollama doesn't support batch inference in CPU mode but it keeps trying on batches and will open up hundreds of connections wait a few seconds and close them. To make matters worse, ollama has to reserve and then release those resources, so it's really slowing ollama down.

I moved embeddings to llama.cpp server and it kind of helps but it's still trying to throw hundreds if not thousands of embedding requests at it then close the connection when the response isn't immediate.

This is an open source project so there's probably a way to fix this buried in the code somewhere. I wish I were more familiar with the embeddings generation side of this tool. It's probably just someone heard about batch embeddings and presumed every embeddings endpoint could handle it. So they implemented batching to try and speed things up, but it doesn't help if the endpoint doesn't support it and it will generate junk embeddings in the case of ollama.

Here's what I'm seeing with llama.cpp server BTW

srv  cancel_tasks: cancel task, id_task = 2947
srv  cancel_tasks: cancel task, id_task = 3006
srv  cancel_tasks: cancel task, id_task = 2946
srv  cancel_tasks: cancel task, id_task = 2645
srv  cancel_tasks: cancel task, id_task = 2897
srv  cancel_tasks: cancel task, id_task = 2896
srv  cancel_tasks: cancel task, id_task = 2895
srv  cancel_tasks: cancel task, id_task = 2894
srv  cancel_tasks: cancel task, id_task = 2893
srv  cancel_tasks: cancel task, id_task = 2892
srv  cancel_tasks: cancel task, id_task = 2891
srv  cancel_tasks: cancel task, id_task = 2890
srv  cancel_tasks: cancel task, id_task = 2889
srv  cancel_tasks: cancel task, id_task = 2888
srv  cancel_tasks: cancel task, id_task = 2887
srv  cancel_tasks: cancel task, id_task = 2886
srv  log_server_r: request: POST /v1/embeddings 172.17.0.1 200
srv  log_server_r: request: POST /v1/embeddings 172.17.0.1 200
srv  log_server_r: request: POST /v1/embeddings 172.17.0.1 200
srv  log_server_r: request: POST /v1/embeddings 172.17.0.1 200
srv  log_server_r: request: POST /v1/embeddings 172.17.0.1 200
srv  log_server_r: request: POST /v1/embeddings 172.17.0.1 200
srv  log_server_r: request: POST /v1/embeddings 172.17.0.1 200
srv  log_server_r: request: POST /v1/embeddings 172.17.0.1 200
srv  log_server_r: request: POST /v1/embeddings 172.17.0.1 200
srv  log_server_r: request: POST /v1/embeddings 172.17.0.1 200

[DexterHuang]

Maybe a fast solution is just add a option to have kilo query the embedding one by one, it's better to be slow (anyway it can just run in the background) then crashing the whole IDE

[Pevernow]

+1 the same error

[hoanggia7398]

I have same issue

[Pevernow]

@chrarnoldus Sorry to bother you, but any response?

[cturan]

Same problem, whole ide crash when I activate indexing.

[chrarnoldus]

Are any of you using Swift?

[cturan]

Are any of you using Swift?

Yes, there are swift codes in my project.

[muhammadgsalem]

I'm having the same issue with iOS projects written in Swift

[Pevernow]

Hey everyone, I've got a solution for you!

1. Find the directory containing the Swift files in your project.
2. Create a new file called .kilocodeignore in the project's root directory.
3. Configure it just like you would .gitignore, specifying the directories containing the Swift files, or even simpler, simply exclude all files ending in .swift.

Then you can enjoy your codebase.

If you encounter the "Could not find ripgrep binary" error on Windows:

Find C:\Users(your username)\AppData\Local\Programs\cursor\resources\app

In this directory, open a terminal with administrator privileges and run npm install @vscode/ripgrep. This will fix the problem.

[aldinokemal]

if you are using MACOS and missing ripgrep:

can go to /Applications/Cursor.app/Contents/Resources/app npm install @vscode/ripgrep

[muhammadgsalem]

Hey everyone, I've got a solution for you!

1. Find the directory containing the Swift files in your project.
2. Create a new file called .kilocodeignore in the project's root directory.
3. Configure it just like you would .gitignore, specifying the directories containing the Swift files, or even simpler, simply exclude all files ending in .swift.

Then you can enjoy your codebase.

If you encounter the "Could not find ripgrep binary" error on Windows:

Find C:\Users(your username)\AppData\Local\Programs\cursor\resources\app

In this directory, open a terminal with administrator privileges and run npm install @vscode/ripgrep. This will fix the problem.

Thank you, it fixed the issue 🙌

[Pevernow]

Adding to the discussion, I've discovered a new issue. Even using the above method, manually ignoring the index in the Swift code, only the first index is complete.

There's still a certain chance of subsequent crashes. The cause is unknown, but it seems to be related to the vector database.

[aldinokemal]

I also encounter same issue, for now I uninstall first until this bug was resolved

actually when your codebase indexing was done it won't making any lag or issue

but during indexing, it seems taking all resources and make IDE lag, very lag

[rodion-m]

Guys, issues with large codebases can be easily solved with CodeAlive MCP