#grey screen of death

50 messages · Page 1 of 1 (latest)

dusty lichen
#

It's so weird that a certain groups of users runs into this consistently and others don't or seldom

midnight pumice
#

Yes. I beta tested the PRs back on the Roo side. Dan was always concerned about memory usage but it never was a problem.

I literally tested CBI the two weekends on 12 different codebases. CBI has issues, but I dont think memory is one of them.

I am curious if @nimble mural 's task history clearout has kept the GSOD's at bay for him

azure fulcrum
azure fulcrum
#

It may not be codebase indexing, still crashed when it is off.

dusty lichen
#

No sorry for the confusion i don't think it has to do with codebase indexing

fading swallow
#

@dusty lichen @midnight pumice @boreal axle FYI

V8 uses a sophisticated memory management system designed for high-performance JavaScript execution:

Memory Spaces

  1. Young Space (Fast Allocation)

    • Eden: New objects are allocated here first
    • Survivor Spaces: Two semi-spaces (S0, S1) for objects that survive garbage collection
    • Uses bump allocation (very fast, just increments a pointer)
    • Small objects (< 1MB) go here initially

  2. Old Space (Long-lived Objects)

    • Old Pointer Space: Objects containing pointers to other objects
    • Old Data Space: Objects containing only raw data (no pointers)
    • Uses mark-sweep-compact garbage collection
    • Objects promoted from Young Space or allocated directly here

  3. Large Object Space

    • Objects ≥ 1MB go directly here
    • No compaction (to avoid expensive moves)
    • Managed with mark-sweep only

Garbage Collection Strategy

V8 uses a generational garbage collection approach:

  • Minor GC (Scavenge): Fast collection of Young Space
  • Major GC (Mark-Sweep-Compact): Full heap collection when needed
  • Incremental Marking: Background marking to reduce pause times
  • Concurrent Sweeping: Parallel sweeping during execution

Memory Limits

  • Default Heap Size: ~1.4GB on 64-bit systems
  • Young Space: ~16-64MB (configurable)
  • Old Space: Rest of the heap
  • V8 Flags: Can be tuned with --max-old-space-size, --max-new-space-size, etc.

Why This Matters for VS Code Extensions

VS Code extensions run in a Node.js process powered by V8. Memory fragmentation occurs when:

  1. Frequent large allocations create holes in the Old Space
  2. No compaction means holes can't be filled efficiently
  3. GC pressure increases as free memory becomes scattered
  4. Extension crashes when approaching the ~1.4GB limit
midnight pumice
#

Avoid global variables
This advice is wildly funny seeing its for JavaScript, the 2nd most promiscuously re-definable language in existence, right after LISP 😂

fading swallow
#

GSOD is caused by memory fragmentation under V8 with frequent large allocations 🙂

fallen apex
#

Scrolled through here and didn't see this mentioned so sharing my workaround when I get GSOD: Open VScode top search type >R and select (Developer: Reload Window), then I open KiloCode histoy to repoen the last conversation and click Resume.

fluid fern
#

I am getting the grey screen every hour.

midnight pumice
fluid fern
#

Using claude code with Kilo. Flutter app. Very frequent crashes

dusty stirrup
#

Several times a day consistently

image.png
fallen apex
dusty stirrup
fallen apex
dusty stirrup
fallen apex
#

damn, then I am out of ideas, Mac is not my territory, sorry :/

dusty stirrup
fallen apex
timber helm
#

I encountered a grey screen issue when I asked "VN president" in Orchestrator mode using the Playwright MCP server.

It consumed around 9M input tokens and about 6K output tokens in ~1h before the issue happened

image.png
#

I clicked this button and resume the task

image.png
timber helm
#

Pause before potential out-of-memory crash

image.png
dense ledge
#

Roo updated with possible grey screen fix

midnight pumice
vast lance
vast lance
# vast lance

I got this when scrolling back up through the message stream to find a particular part i wanted to reread. It was long about 230k worth of tokens and it was lagging as it does and then boom....Grey Screen of Death. I was idle at the time so no api calls or any other sort of processing going on.

dusty lichen
#

Yeah this is the infamous gray screen. It is caused by excessive memory usage in the view layer of vs code, so no calls, but you looking at a lot of data in the ui sounds in line. Actually, if you could reproduce it and are able (not sure how private this code/chat is) to share the session it might help us pinpoint a cause

vast lance
dusty lichen
#

No worries. Try to break it up next time with orchestrator, or use /newtask, or manually start anew. Typically when you have such a long session the quality of llm responses will decrease as well

midnight pumice
#

Orchestrator is overall an excellent choice for large things. Costs a few Kilo bucks but makes all the Subtasks much smaller and less prone to GSOD

boreal dove
# timber helm https://youtu.be/JefQKzC1ZUI?si=fo4NKMEklIaAzeAu&t=516

I don't know if someone has observed this or not but this death grey screen is appearing when:

  1. The ram is low
  2. Spike in context size of the model
  3. again the sudden ram usage spike which when checked later after the grey screen appears normal because kilo process become low

so conclusion i solved for my system is increased the ram size and dedicated some space to kilo only to work and making sure that my context size is under limit.

dusty lichen
#

You say spike of context size, so it lowers again? This would imply it has something to do with condensing?

boreal dove
#

well my apologies first for not knowing the exact keywords for as i'm just a founder of not so popular tech company and doesn't know that much about ai.

#

So back to the topic yes context size lowers again because of crash along with the ram usage of kilo code and yes there maybe some issue with context size and ram

#

Like you know when we run a unoptimized game in beta testing or some heavy website

#

that at somepoint use so much of specs and then right after the next second lowers it beast mode running everything smoothly

#

and in my case when im facing this issue i just though that maybe my pc is mid spec so i upgraded the ram and after that i never faced this issue
My old limit for opening vs code kilo extension is 3 and when i drop a context very lengthy bomb over kilo it crashes and now i can open 5 window do things smoothly in chunks making sure that atleast 4gb of ram is on standby and i'm good

#

it's getting very lengthy so if you want me to test something crazy just dm me i sit around 15 hours a day in front of my screen so i can help and contribute more

#

CYA

#

@dusty lichen

dusty lichen
#

Thx, that's helpful. Then we can at least look into whether something is happening around context condensing. I do agree with your experience btw; I have a high spec pc and almost never run into grey screen even when running a lot of vscode/kilo in parallel

sharp abyss
#

Whats odd is for RooCode they had it fixed in: 3.28.18, then shortly after there was a regression. Has anyone done a diff since? Almost like someone didn't git fetch before subsequent release. Anything the 3 projects can learn from that release?

Also tested 3.28.18 myself, no issues with GSOD.

midnight pumice
#

IIRC they removed responses from going back into the history (if you go search Roo # General you can see Hannes' Eureka! Moment)

But it think it caused an issue if you rolled back and tried to resume a conversation

timber helm
#

I believe this grey-screen issue is more likely tied to context length than to my PC’s hardware.

I'm using an Intel Core i7-14700K, 1.5 TB SSD, 32 GB RAM and an RTX 3060 and I still have plenty of free RAM when the grey screen appears. I suspect the "Context Condensed" feature may be causing the fault.

#

Has anyone else been able to reproduce this bug?

That's really strange.

I haven't seen it in a long time, so I thought KiloCode had already fixed it :v