Where does the bug appear (feature/product)?
Cursor IDE
Describe the Bug
All Cursor windows closed at once, with no error dialog. The main (browser) process crashed itself with exit code 0x80000003 (STATUS_BREAKPOINT, a fatal CHECK) at 2026-11-07 07:16:49.165 UTC (15:16:49 local time, UTC+8), after 2 h 38 min of uptime. Nobody was using the computer at the time.
The failing check is in Chromium’s Perfetto tracing code:
Cursor.exe+0x3d137ae
perfetto::SharedMemoryArbiterImpl::BindToProducerEndpoint(perfetto::ProducerEndpoint*, perfetto::base::TaskRunner*) +0x25e
third_party/perfetto/src/tracing/core/shared_memory_arbiter_impl.cc:752
PERFETTO_CHECK(IsReservationTargetBufferId(entry.second));
It happened during a drain cycle of Cursor’s GC trace polling (the gc_trace_control experiment). This feature keeps contentTracing recording disabled-by-default-v8.gc continuously and runs stop → read → restart every 120 s. I did not turn it on, and I can’t find a setting to turn it off.
Steps to Reproduce
The crash is not deterministic. The conditions when it happened:
- Windows 11 with Cursor 3.29.9, and GC trace polling active. Every window’s
renderer.logcontains[GC Trace Polling] Started polling (every 130s). - Cursor had been running for a few hours with 5 windows open.
- One drain cycle overlapped with the main process launching a new sandboxed child process, presumably a replacement tracing service, and the main process crashed 0.23 s later.
Expected Behavior
A failure in background GC tracing should not take down the main process, along with every open window and integrated terminal session.
Operating System
Windows 10/11
Version Information
Version: 3.29.9 (user setup)
VSCode Version: 1.128.0
Commit: 306d153d51d714882ab7b1bc49649cab624e8a30
Date: 2026-11-05T02:42:01.412Z
Electron: 43.8.4
Chromium: 150.0.7871.250
OS: Windows_NT x64 10.0.22631
Windows 11 Home 23H2 (10.0.22631), x64
Additional Information
Timeline (UTC; local time is UTC+8)
| Time (UTC) | Event |
|---|---|
| 04:38:28.960 | Main process starts |
| 04:38:43.146 | window1 renderer.log: [GC Trace Polling] Started polling (every 130s) |
| every 120 s | Drain: a GUID-named .tmp trace file in %TEMP% is written, parsed and deleted |
| 07:16:47.306 | A drain starts and creates %TEMP%\f408901b-93c1-4eb6-81a5-efde4a08b9a4.tmp |
| 07:16:48.628 | Last write to that file. It stays at 0 bytes and is never deleted; it is still on disk. |
| 07:16:48.932 | The main process launches a new sandboxed child, PID 35432. Windows Security-Mitigations event 10 for it appears at 07:16:48.952. Earlier drains did not launch processes. |
| 07:16:49.165 | The main process exits with 0x80000003. The other child processes exit within the next ~140 ms. PID 35432 exits with code 0, having used no CPU time. |
| 08:14:39 | Next Cursor launch. The bundled @sentry/electron minidump integration picks up the dump from %APPDATA%\Cursor\Crashpad\reports and deletes it. |
Notes
- The check should be unreachable. At the pinned Perfetto revision,
pending_writers_is written in only one place,shared_memory_arbiter_impl.cc:1020. That write happens only whenIsReservationTargetBufferId(target_buffer)is true, i.e. when the upper 16 bits are non-zero. Every access is underlock_. - So the state was probably corrupted. The arbiter found an entry with the upper 16 bits clear. That points to corrupted state, a use-after-free of the arbiter or its map, or a race, rather than an unusual but legal call sequence. This is my reading of the source; I may be missing a path.
- The old tracing service had already gone. The tracing-service process the main process had been using was no longer present when the new child was launched. I could not determine when or why it exited.
- I could not confirm what PID 35432 was. I could not recover its command line, so “replacement tracing service” is an inference.
- A child launch was in progress at crash time. Stack data found next to the exception record includes
content::ChildProcessLauncherHelper::StartLaunchOnClientThreadandsandbox::BrokerServicesBase::SpawnTargetAsyncImplon the browser IO thread.
How the crash location was obtained (the local minidump had already been deleted)
- The dead session’s
crashpad_handlerwas still running and still held a handle to the dead main process.GetExitCodeProcess/GetProcessTimeson that process gave exit code0x80000003and the exit time. - I took a full memory dump of that
crashpad_handler(cdb -pv -p <pid> -c ".dump /ma ..."). It still contained theEXCEPTION_RECORD(code0x80000003, address0x7ff643f337ae) and the CPU context, withrip = 0x7ff643f337ae. - I symbolized
Cursor.exe+0x3d137aewith the official Electron 43.8.4 Breakpad symbols fromsymbols.electronjs.org; their module ID matchesCursor.exe. The result isBindToProducerEndpoint +0x25e, line 752. - The disassembly of
Cursor.exeagrees:- The
pending_writers_loop doescmp dword ptr [node+24h],0FFFFh/jbeto a cold block. - That block calls the log function with line
0x2F0(= 752) and ends in theint 3at RVA0x3d137ae. - The checks at lines 737 and 738 have their own separate crash blocks, so this is not a merged trap site.
- The
- The source is Perfetto
9ede949f025303868fa0c42418f122ac47312539, the revision pinned in the DEPS of Chromium 150.0.7871.250.
Requests
- If the Sentry minidump upload succeeded, the crash should be in your Sentry with this signature, uploaded around 2026-11-07 08:14 UTC. I can send my crash reporter ID privately if that helps you find it.
- Please consider turning off
gc_trace_controluntil this is understood, at least on Windows with this Chromium version. Users have no way to turn it off themselves. - Since the check looks unreachable under Perfetto’s own invariants, it may be worth raising with the Chromium/Perfetto teams.
I analyzed this one occurrence in detail. Cursor has also closed unexpectedly at other times, but I have no evidence tying those to this crash.
Does this stop you from using Cursor
Sometimes - I can sometimes use Cursor