Skip to content

Bug: Node.js processes leak during repeated debug sessions, causing system resource exhaustionΒ #5397

@hannesrudolph

Description

@hannesrudolph

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

  1. Open any workspace in VSCode with the Roo Code extension installed
  2. Start debugging using Run > Start Debugging from the menu (or press F5)
  3. Close the debug session by either:
    • Stopping debugging via the debug toolbar
    • Closing VSCode entirely
  4. Repeat steps 2-3 multiple times during normal development work
  5. Open your system's process monitor (Activity Monitor on macOS, Task Manager on Windows)
  6. 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:

  1. Register for VSCode debug session events
  2. Create a centralized ProcessRegistry to track all spawned processes
  3. Enhance the deactivation handler to kill all tracked processes
  4. Implement process tree killing to ensure child processes are cleaned up
  5. 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

No one assigned

    Labels

    Issue - Needs ScopingValid, but needs effort estimate or design input before work can start.bugSomething isn't working

    Type

    No type

    Projects

    Status

    Done

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions