-
Notifications
You must be signed in to change notification settings - Fork 2.6k
Description
Description
π¨ Critical Process Lifecycle Management Issue
The Roo Code VSCode extension has a critical bug where Node.js processes spawned during debug sessions are not properly cleaned up, leading to orphaned processes that accumulate and consume approximately 1GB of memory each. This represents a significant resource leak that affects all users who debug other projects while the Roo Code extension is active.
When users repeatedly start and stop debug sessions during normal development workflows, these orphaned processes persist even after VSCode is closed, eventually overwhelming system resources. This is a 100% reproducible issue that severely impacts developer productivity and system performance.
Steps to Reproduce
- Open any workspace in VSCode with the Roo Code extension installed
- Start debugging using Run > Start Debugging from the menu (or press F5)
- Close the debug session by either:
- Stopping debugging via the debug toolbar
- Closing VSCode entirely
- Repeat steps 2-3 multiple times during normal development work
- Open your system's process monitor (Activity Monitor on macOS, Task Manager on Windows)
- Observe orphaned Node.js processes accumulating, each consuming ~1GB memory
Note: The issue occurs when debugging any project, not just the Roo Code extension itself.
Expected Behavior
- Debug sessions should properly clean up all spawned processes when terminated
- No orphaned Node.js processes should remain after debug sessions end
- Process cleanup should occur automatically without user intervention
- System resources should be freed when debug sessions complete
Actual Behavior
- Node.js processes accumulate and persist after debug sessions end
- Each orphaned process consumes approximately 1GB of memory
- Processes remain active even after VSCode is closed
- Memory usage grows unbounded with each debug session
- System performance degrades as resources are exhausted
Environment
- OS: macOS Sonoma (also affects Windows and Linux)
- VSCode Version: 1.101.2
- Extension Version: Latest Roo Code extension
- Node.js Version: System default
- Frequency: Always - 100% reproducible
Technical Context
Based on codebase analysis, the root cause appears to be:
1. Missing Debug Session Lifecycle Hooks
The extension does not register for VSCode debug session events (onDidStartDebugSession, onDidTerminateDebugSession), meaning it has no awareness of when debug sessions start or end.
2. Incomplete Deactivation Handler
The current deactivation handler in src/extension.ts:215-220 only cleans up:
- MCP servers
- Telemetry service
- Terminal registry
It does not handle:
- Active debug session processes
- Child processes spawned by terminals
- Processes created outside the terminal/MCP infrastructure
3. No Central Process Registry
The codebase lacks a centralized mechanism to track all spawned processes. Processes are created through multiple mechanisms:
- Terminal processes via
ExecaTerminalProcess - MCP server processes
- Direct process spawning in Claude Code integration
- Detached processes in the evaluation system
4. Reference Counting Issues
The MCP Hub uses reference counting for cleanup, which may not trigger disposal during rapid debug session restarts, allowing processes to accumulate.
Additional Context
- Impact: This affects all users who use the Roo Code extension while debugging other projects
- Workaround: Users must manually kill orphaned processes through system process monitors
- Resource Impact: With ~1GB per process, just 8-16 debug sessions can consume most available memory on typical developer machines
- Discovery: Issue was discovered when system became unresponsive after a day of normal development work
Potential Solution Approach
The fix requires implementing proper debug session lifecycle management:
- Register for VSCode debug session events
- Create a centralized
ProcessRegistryto track all spawned processes - Enhance the deactivation handler to kill all tracked processes
- Implement process tree killing to ensure child processes are cleaned up
- Add timeout-based fallback from SIGTERM to SIGKILL
Note: I am planning to contribute a fix for this issue and would appreciate any guidance on the preferred implementation approach.
Metadata
Metadata
Assignees
Labels
Type
Projects
Status