[Devin Desktop v3.10.23] Renderer process OOM crash (reason: oom, code: -536870904) — 53 crashes in 44 days, NOT fixed in latest build

[stratte89]

Bug Report: Renderer process OOM crash during long-running Devin ACP chat sessions

RE-REPORT — Bug persists on v3.10.23 (latest stable, Sep 10 2026)

This is a re-report. The original report (Aug 28, 2026) documented 33 OOM crashes over 30 days on v1.126.0. The bug was NOT fixed. The changelog for v3.10.23 (Sep 10, 2026) mentions "bounded memory for background transcripts and streamed file writes" — this does NOT address the renderer event listener leak. 20 additional OOM crashes have occurred since the original report (Aug 28 – Sep 11, 2026), including 3 crashes in the last 36 hours on the latest v3.10.23 build.

Summary

The Devin IDE renderer process crashes repeatedly with reason: oom, code: -536870904 during long-running ACP (Agent Communication Protocol) chat sessions that involve many tool invocations. This is the same V8 heap exhaustion bug documented in upstream VSCode issue #300339 — an event listener leak in the chat tool invocation rendering path (trackToolState/updateTitle/appendToolInvocation). The leaked listeners are never disposed, causing unbounded V8 heap growth until the renderer hits the 4GB pointer-compression cap and is killed by V8.

Environment

Field	Value
Devin Desktop version	v3.10.23 (windsurfVersion, distro e6b302180cc8fecde16d482d0f2add78b067b6bf)
Devin CLI version	devin 3000.10.23 (deb81600)
VSCode base	Fork of VSCode 1.126
OS	Windows 10 Pro 10.0.19045 (Build 19045)
CPU	Intel Core i5-11400 @ 2.60GHz, 6 cores / 12 threads
RAM	48 GB (50,136,684 KB visible)
GPU	(integrated, Intel UHD 730)
Motherboard	MSI MS-7D08

Frequency

53 OOM crashes logged across 9 sessions over 44 days (Jul 30 – Sep 11, 2026), with increasing frequency:

Session	Date range	OOM count	Avg hours between crashes
20260730T000636	Jul 30	2	10 min
20260801T134801	Aug 1 – Aug 10	6	~2 days
20260814T175417	Aug 17 – Aug 23	12	~14 hours
20260823T183856	Aug 23 – Aug 28	13	~8 hours
20260828T152905	Aug 29 – Sep 2	7	~14 hours
20260902T144526	Sep 3 – Sep 6	3	~1 day
20260906T171020	Sep 7 – Sep 8	1 OOM + 1 killed	~10 hours
20260908T005456	Sep 8	1 killed	—
20260909T125025	Sep 10 – Sep 11	3	~8 hours

The trend shows crashes becoming more frequent over time, consistent with a memory leak that accumulates faster as sessions get longer and more tool invocations are rendered.

Error signature

Every crash produces this exact line in main.log:

[error] CodeWindow: renderer process gone (reason: oom, code: -536870904)

Error code -536870904 (0xE0000018) is the V8 OOM exit code. The renderer process is killed by V8 when the JavaScript heap exceeds the pointer-compression cage limit of 4GB.

Full OOM timeline (all 53 events)

--- Original report (Jul 30 – Aug 28, 2026): 33 crashes ---
2026-07-30 15:32:27  renderer process gone (reason: oom)
2026-07-30 15:42:53  renderer process gone (reason: oom)
2026-08-01 23:14:44  renderer process gone (reason: oom)
2026-08-02 13:18:29  renderer process gone (reason: oom)
2026-08-02 22:26:05  renderer process gone (reason: oom)
2026-08-02 23:52:49  renderer process gone (reason: oom)
2026-08-04 04:13:29  renderer process gone (reason: oom)
2026-08-10 19:05:26  renderer process gone (reason: oom)
2026-08-17 15:23:45  renderer process gone (reason: oom)
2026-08-18 13:54:32  renderer process gone (reason: oom)
2026-08-19 05:13:30  renderer process gone (reason: oom)
2026-08-20 18:06:01  renderer process gone (reason: oom)
2026-08-20 23:43:05  renderer process gone (reason: oom)
2026-08-21 19:32:07  renderer process gone (reason: oom)
2026-08-21 23:28:52  renderer process gone (reason: oom)
2026-08-22 03:29:21  renderer process gone (reason: oom)
2026-08-22 07:44:35  renderer process gone (reason: oom)
2026-08-22 17:29:12  renderer process gone (reason: oom)
2026-08-22 21:53:35  renderer process gone (reason: oom)
2026-08-23 00:55:56  renderer process gone (reason: oom)
2026-08-23 18:26:51  renderer process gone (reason: crashed, code: -36863)
2026-08-23 23:59:00  renderer process gone (reason: oom)
2026-08-24 13:41:15  renderer process gone (reason: oom)
2026-08-24 19:38:27  renderer process gone (reason: oom)
2026-08-24 22:06:44  renderer process gone (reason: oom)
2026-08-25 05:27:21  renderer process gone (reason: oom)
2026-08-25 22:34:08  renderer process gone (reason: oom)
2026-08-26 14:33:43  renderer process gone (reason: oom)
2026-08-26 18:08:55  renderer process gone (reason: oom)
2026-08-27 08:25:54  renderer process gone (reason: oom)
2026-08-27 19:06:39  renderer process gone (reason: oom)
2026-08-27 22:09:14  renderer process gone (reason: oom)
2026-08-28 10:38:49  renderer process gone (reason: oom)

--- NEW crashes since original report (Aug 28 – Sep 11, 2026): 20 crashes ---
2026-08-28 14:26:57  renderer process gone (reason: oom)
2026-08-29 20:39:34  renderer process gone (reason: oom)
2026-08-30 15:53:18  renderer process gone (reason: oom)
2026-08-30 16:05:58  renderer process gone (reason: oom)
2026-08-31 07:45:30  renderer process gone (reason: oom)
2026-09-01 03:42:35  renderer process gone (reason: oom)
2026-09-01 19:12:55  renderer process gone (reason: oom)
2026-09-02 01:00:44  renderer process gone (reason: oom)
2026-09-03 04:34:39  renderer process gone (reason: oom)
2026-09-03 21:08:27  renderer process gone (reason: oom)
2026-09-06 07:40:11  renderer process gone (reason: oom)
2026-09-07 14:32:48  renderer process gone (reason: oom)
2026-09-08 00:51:55  renderer process gone (reason: killed, code: 1)
2026-09-08 14:36:56  renderer process gone (reason: killed, code: 1)
2026-09-10 02:13:51  renderer process gone (reason: oom)  ← v3.10.23
2026-09-11 00:46:52  renderer process gone (reason: oom)  ← v3.10.23
2026-09-11 14:17:51  renderer process gone (reason: oom)  ← v3.10.23 (today, ~5h ago)

Symptoms before crash

In the hours/minutes before each OOM, the renderer logs show escalating extension host unresponsiveness:

[info] Extension host (LocalProcess pid: 33736) is unresponsive.
[warning] Extension Host health check: RPC Protocol state is unresponsive
[info] Extension host (LocalProcess pid: 33736) is responsive.
[info] UNRESPONSIVE extension host: received responsive event and cancelling profiling session
[info] UNRESPONSIVE extension host: starting to profile NOW

These unresponsive cycles repeat with increasing frequency as memory pressure builds, eventually culminating in the OOM kill.

Root cause analysis

This matches upstream VSCode issue #300339 exactly:

"VS Code's renderer process crashes with OOM (reason: 'oom', code: '-536870904') during long-running Copilot Chat agent sessions. The root cause is an event listener leak in the chat tool invocation rendering path — listeners attached by trackToolState/updateTitle in tool invocation widgets are never disposed, causing unbounded memory growth until the renderer hits its V8 heap limit."

Key findings from our logs that confirm this:

1. The leak is proportional to tool invocations, not conversation length — sessions with many Devin CLI tool calls (grep, read, exec) crash faster than sessions with fewer calls.
2. Re-loading an old chat session re-creates the leak — when the renderer restarts after an OOM and re-loads the chat history, all past tool invocation widgets are re-rendered, re-attaching the leaked event listeners. The leak rebuilds from where it left off.
3. The V8 heap cap is 4GB regardless of system RAM — V8 pointer compression (since V8 9.2) imposes a hard 4GB limit on the JS heap per process. The user has 48GB RAM but the renderer cannot use more than 4GB of V8 heap. This is a compile-time architectural limit in V8/Electron that cannot be changed at runtime.
4. The default V8 old-space limit may be lower than 4GB — setting --max-old-space-size=4096 in argv.json raises it to the architectural maximum, but does not prevent the eventual crash. It only extends the runway.

Reproduction

1. Open Devin IDE with a workspace
2. Start a Devin CLI ACP chat session
3. Have the agent perform many tool invocations (100+ grep/read/exec calls over a few hours)
4. Observe the renderer memory growing in Task Manager
5. After several hours (2-17 hours depending on tool invocation density), the renderer crashes with reason: oom, code: -536870904
6. Devin auto-reloads the window and re-loads the chat history
7. Continuing the same chat session causes the leak to rebuild and crash again

Impact

• Lost work context — each crash reloads the window, losing terminal state, open file tabs, and scroll positions
• Chat history re-rendering — re-loading old sessions immediately re-creates the leak, so crashes become more frequent over time
• No warning — the crash happens without any user-facing notification; the window just reloads
• Productivity loss — 53 crashes in 44 days, averaging ~1.2 per day, with sessions lasting only 2-17 hours before crashing
• Bug NOT fixed in v3.10.23 — the latest stable release (Sep 10, 2026) includes "bounded memory for background transcripts and streamed file writes" but this does NOT address the renderer event listener leak. 3 OOM crashes occurred on v3.10.23 within 36 hours of installation.

Workarounds attempted

Workaround	Effect	Status
--max-old-space-size=4096 in argv.json	Raises V8 old-space from ~2-3GB to 4GB max	Applied, but requires full IDE restart (not yet restarted)
extensions.experimental.extensionHostV8Flags in settings.json	Same flag for extension host process	Applied
Starting a NEW chat session (not continuing old one)	Clears accumulated leaked listeners	Effective but loses conversation context
Deleting stale session lock files	No effect on OOM	Housekeeping only — lock files are unrelated to renderer memory
Deleting old ACP session metadata from state.vscdb	Would reduce re-rendered widgets on reload	Rejected by user — would lose chat history access

What we need from the Devin team

1. Port the fix from VSCode #300339 — ensure event listeners in tool invocation widgets (trackToolState, updateTitle, appendToolInvocation, createToolInvocationSubPart, _updateParentChangeListener) are properly disposed when tool invocations complete or when conversation history is compacted.
2. Consider not re-rendering all past tool invocation widgets on session reload — if the widgets are only needed for display, consider a virtualized/lazy-rendered approach that doesn't attach event listeners for off-screen or completed tool invocations.
3. Add a memory pressure indicator — warn the user before the OOM happens, not after. The escalating extension host unresponsiveness cycles are a clear precursor signal.
4. Consider a "compact history" action — let users compact old tool invocations in the current session without losing the conversation, freeing the leaked listeners.

Log file locations

All logs are available on the reporting machine:

Log	Path
Main log (OOM events)	C:\Users\privat\AppData\Roaming\Windsurf\logs\<session>\main.log
Renderer logs	C:\Users\privat\AppData\Roaming\Windsurf\logs\<session>\windowN\renderer.log
Devin extension logs	C:\Users\privat\AppData\Roaming\Windsurf\logs\<session>\windowN\exthost\codeium.windsurf\Devin*.log
Devin CLI logs	C:\Users\privat\AppData\Roaming\Devin\cli\logs\devin_*.log
argv.json (V8 flags)	C:\Users\privat\.devin\argv.json
Settings	C:\Users\privat\AppData\Roaming\Windsurf\User\settings.json

Related upstream issues

• VSCode #300339 — Renderer OOM crash: event listener leak in chat tool invocation UI
• VSCode #303526 — VS Code renderer repeatedly crashes with OOM during heavy workspace sessions
• VSCode #266716 — Copilot OOM (Node.js)
• Electron #31330 — Memory limitations introduced with Electron 14+ (V8 pointer compression 4GB cap)
• V8 pointer compression — Technical explanation of the 4GB heap cap