Skip to content
LogScope Docs

v0.5.18

Released: 2026-05-12

Critical fix for an orphan-helper bug that left LogScope appearing connected with zero entries after a VS Code window reload.

Fixed

Section titled “Fixed”
  • Reloading VS Code while LogScope is connected no longer leaves an orphan helper holding the J-Link probe. When VS Code reloads its window, the extension host is torn down immediately. Previously, disconnect() queued the force-kill of the Python helper subprocess via a 500ms setTimeout — which never fired because the event loop was already dead. The helper survived as an orphan re-parented to init (PID 1), kept polling RTT, and silently drained log data away from any subsequent LogScope session. The next “Connect” looked successful (probe is multiplexed across processes by SEGGER’s J-Link service) but no entries ever appeared because the orphan was reading the RTT buffer first. Fix: two layers of defense.
    • Layer 1 (extension): disconnect() now kills the helper synchronously instead of via setTimeout. The graceful quit\n message still goes out first (best-effort), but a SIGTERM follows immediately on the same tick. disconnectAll() also now cleans up mid-connect transports (helper spawned but RTT_READY not yet seen), which had the same orphan risk.
    • Layer 2 (Python helper): rtt-helper.py now installs a SIGTERM handler that exits cleanly via os._exit(0), and a daemon thread that polls os.getppid() every 2 seconds. If our parent process dies (PID changes, or becomes 1 on Unix), the helper bails immediately, releasing the J-Link probe. This catches edge cases where Layer 1’s signal never arrives (extension host crashed, etc.). Windows orphan detection works differently and is tracked as future work.