I was trying to troubleshoot some weird behavior in my ESLint package this morning, hence was reloading the window on a rather large work project. Out of maybe twenty reloads, three of them caused a crash.
The crash reports are all identical:
Details
-------------------------------------
Translated Report (Full Report Below)
-------------------------------------
Process: Pulsar Helper (Renderer) [73017]
Path: /Applications/Pulsar.app/Contents/Frameworks/Pulsar Helper (Renderer).app/Contents/MacOS/Pulsar Helper (Renderer)
Identifier: dev.pulsar-edit.pulsar.helper.Renderer
Version: 1.131.1
Code Type: ARM-64 (Native)
Role: Foreground
Parent Process: Pulsar [92041]
Coalition: dev.pulsar-edit.pulsar [80885]
Responsible Process: Pulsar [92041]
User ID: 502
Date/Time: 2026-02-25 13:44:18.7069 -0800
Launch Time: 2026-02-25 13:04:28.9784 -0800
Hardware Model: Mac16,8
OS Version: macOS 26.2 (25C56)
Release Type: User
Crash Reporter Key: C9DD281E-45C6-ABF0-72A5-9B8CFC9CF5F0
Incident Identifier: 1A554919-A00E-4CF6-B048-79BB9F56FFA4
Sleep/Wake UUID: E5999F6D-1A00-4373-8BA2-EDBF0949ECFE
Time Awake Since Boot: 800000 seconds
Time Since Wake: 14372 seconds
System Integrity Protection: enabled
Triggered by Thread: 0 CrRendererMain, Dispatch Queue: com.apple.main-thread
Exception Type: EXC_CRASH (SIGABRT)
Exception Codes: 0x0000000000000000, 0x0000000000000000
Termination Reason: Namespace SIGNAL, Code 6, Abort trap: 6
Terminating Process: Pulsar Helper (Renderer) [73017]
Application Specific Information:
abort() called
Thread 0 Crashed:: CrRendererMain Dispatch queue: com.apple.main-thread
0 libsystem_kernel.dylib 0x19e7af5b0 _pthread_kill + 8
1 libsystem_pthread.dylib 0x19e7e9888 pthread_kill + 296
2 libsystem_c.dylib 0x19e6ee850 abort + 124
3 Electron Framework 0x114316d8c node::Buffer::New(v8::Isolate*, char*, unsigned long) + 168184
4 Electron Framework 0x1143169fc node::Buffer::New(v8::Isolate*, char*, unsigned long) + 167272
5 Electron Framework 0x11425d41c node::MakeCallback(v8::Isolate*, v8::Localv8::Object, v8::Localv8::Function, int, v8::Localv8::Value*, node::async_context) + 348
6 git.node 0x109ad11ac Nan::Callback::Call(v8::Isolate*, v8::Localv8::Object, int, v8::Localv8::Value, Nan::AsyncResource) const + 120
7 git.node 0x109ad1350 Nan::Callback::Call(int, v8::Localv8::Value) const + 192
8 git.node 0x109ad14d4 Repository::GetStatusAsync(Nan::FunctionCallbackInfov8::Value const&)::StatusAsyncWorker::HandleOKCallback() + 64
9 git.node 0x109ad0f20 Nan::AsyncWorker::WorkComplete() + 72
10 git.node 0x109ad0d18 Nan::AsyncExecuteComplete(uv_work_s, int) + 32
11 Electron Framework 0x10d5d3c5c uv_barrier_destroy + 1180
12 Electron Framework 0x10d5d72f8 uv_async_send + 1168
13 Electron Framework 0x10d5e7e4c uv_free_interface_addresses + 1960
14 Electron Framework 0x10d5d77c0 uv_run + 372
15 Electron Framework 0x10d77b1a8 node::FreeArrayBufferAllocator(node::ArrayBufferAllocator*) + 18308
16 Electron Framework 0x1108dd120 std::sys::pal::unix::os::errno::h12fdde1c2329795a + 279504
17 Electron Framework 0x1108f7600 std::sys::pal::unix::os::errno::h12fdde1c2329795a + 387248
18 Electron Framework 0x1108f7c10 std::sys::pal::unix::os::errno::h12fdde1c2329795a + 388800
19 Electron Framework 0x11089ec10 std::sys::pal::unix::os::errno::h12fdde1c2329795a + 24256
20 Electron Framework 0x1108f8278 std::sys::pal::unix::os::errno::h12fdde1c2329795a + 390440
21 Electron Framework 0x1108c35a8 std::sys::pal::unix::os::errno::h12fdde1c2329795a + 174168
22 Electron Framework 0x113fe2e38 node::CommonEnvironmentSetup::event_loop() const + 8804076
23 Electron Framework 0x10d90e7bc v8::CodeEvent::GetScriptLine() + 379156
24 Electron Framework 0x10d90f4b8 v8::CodeEvent::GetScriptLine() + 382480
25 Electron Framework 0x10d90de5c v8::CodeEvent::GetScriptLine() + 376756
26 Electron Framework 0x10d90e020 v8::CodeEvent::GetScriptLine() + 377208
27 Electron Framework 0x10d5e851c ElectronMain + 180
28 Pulsar Helper (Renderer) 0x104044a50 0x104044000 + 2640
29 dyld 0x19e421d54 start + 7184
This points to git-utils as the culprit. git-utils uses native bindings and NAN, but has been declared as context-aware to comply with the new rules in Electron 13+. As far as I know, it is context-aware, but it's possible that the crash is unrelated to context-awareness.
Claude's theory is that git-utils is trying to allocate a Node buffer while “the isolate is in a bad state.” One translation of that phrase is “while the environment is terminating” — i.e., when I've just asked for the window to reload and the environment is therefore being torn down. (This is not unfamiliar to us; a similar issue with nsfw caused routine segfaults on window reload back in the PulsarNext days.)
In this case, the crash is happening while the native module is deep in binding code — not because it's doing some Git-related work. Claude thinks that an async worker was started before the environment started to unload, and then resolved while the environment was terminating — triggering a crash.
Luckily, we do have an N-API rewrite of git-utils lying around. This alone might fix the issue; Claude claims that Napi::AsyncWorker has more awareness of the environment's lifecycle, and that async-worker callbacks will automatically be suppressed in a terminating environment.
I rewrote git-utils in N-API about 16 months ago, back when I was rewriting everything in N-API. There was no pressing need at the time, but at the time I figured I might as well get the exercise in. My recollection is that all the tests pass. So that'd be one way to fix this!
Sadly, I don't have great suggestions about how to reproduce this. I imagine it could be triggered if there were something about a given Git repository that made it very slow to report status — but I don't know how easy that is in the general case. I only ran into it because I was dealing with a behemoth of a project at work.
I also can't demonstrate that this has ever happened when quitting Pulsar. You'd think that any sort of terminating-environment error would be just as likely to surface when quitting the app, yet it hasn't. (Maybe that's just because I reload windows way more often than I quit the app altogether.)
I was trying to troubleshoot some weird behavior in my ESLint package this morning, hence was reloading the window on a rather large work project. Out of maybe twenty reloads, three of them caused a crash.
The crash reports are all identical:
Details
This points to
git-utilsas the culprit.git-utilsuses native bindings and NAN, but has been declared as context-aware to comply with the new rules in Electron 13+. As far as I know, it is context-aware, but it's possible that the crash is unrelated to context-awareness.Claude's theory is that
git-utilsis trying to allocate a Node buffer while “the isolate is in a bad state.” One translation of that phrase is “while the environment is terminating” — i.e., when I've just asked for the window to reload and the environment is therefore being torn down. (This is not unfamiliar to us; a similar issue withnsfwcaused routine segfaults on window reload back in the PulsarNext days.)In this case, the crash is happening while the native module is deep in binding code — not because it's doing some Git-related work. Claude thinks that an async worker was started before the environment started to unload, and then resolved while the environment was terminating — triggering a crash.
Luckily, we do have an N-API rewrite of
git-utilslying around. This alone might fix the issue; Claude claims thatNapi::AsyncWorkerhas more awareness of the environment's lifecycle, and that async-worker callbacks will automatically be suppressed in a terminating environment.I rewrote
git-utilsin N-API about 16 months ago, back when I was rewriting everything in N-API. There was no pressing need at the time, but at the time I figured I might as well get the exercise in. My recollection is that all the tests pass. So that'd be one way to fix this!Sadly, I don't have great suggestions about how to reproduce this. I imagine it could be triggered if there were something about a given Git repository that made it very slow to report status — but I don't know how easy that is in the general case. I only ran into it because I was dealing with a behemoth of a project at work.
I also can't demonstrate that this has ever happened when quitting Pulsar. You'd think that any sort of terminating-environment error would be just as likely to surface when quitting the app, yet it hasn't. (Maybe that's just because I reload windows way more often than I quit the app altogether.)