VimR 0.56.1 (20250725.172504) – freezes after closing the last file in quit mode.

[serge-ivamov]

Hi,

Settings/General: After Last Window Closes: Quit.

VimR 0.56.1 (20250725.172504) – freezes after closing the last file in quit mode.

[taiansu]

Have the same issue here.

My env:

• macbook M1
• Sequoia: 15.6.0 & 15.6.1
• vimr version: 0.47.5 & 0.56.1

After quit vimr, I have to manually kill these running processes in macOS's activity monitor to make vimr work again:

[pabuisson]

Facing the same problem here with:

• Vimr 0.57.1,
• Mac Mini 2018 intel,
• Running Sequoia 15.6.1

And also with:

• Vimr 0.57.1
• Macbook M3,
• Running Sequoia 15.6.1

On this 2nd machine, it was working OK with Vimr 0.52.0 on the same MacOS version.

The app remains open and present in my dock and visible in the running processes as was formerly shown by @taiansu. However, the app does not respond to anything: can't open a file, create a file, or quit. I need to "Force quit" Vimr to be able to do anything with it again.

[georgeharker]

Do you set a custom nvim binary or is is just using the built in? Does it still occur with a minimal config?

[pabuisson]

Good points, I'm sorry I didn't think of it before my previous message.

Do you set a custom nvim binary or is is just using the built in?

I'm using the building nvim binary.

Does it still occur with a minimal config?

It does: I removed my neovim configuration entirely and still get this issue when trying to close Vimr.

That made me think of entirely uninstalling and reinstalling vimr: when I did this (with no neovim configuration and using the built-in neovim binary), just changing the "After last window closed" to "Quit", I still got the same behaviour.

[goduck777]

Have the same issue here. Have to force quit VimR to make it work again.

[iwinux]

Same issue here.

• macOS 15.3.2
• VimR 0.58.0,20251013.211150 + built-in nvim binary + minimal config
• After last window closed: Quit

The app menu looks like:

If I change "After last window closed" to "Do Nothing", then "Quit VimR" will not be grayed out and it quits without hanging.

[iwinux]

This stack sample output might help:

Analysis of sampling VimR (pid 75864) every 1 millisecond
Process:         VimR [75864]
Path:            /Applications/VimR.app/Contents/MacOS/VimR
Load Address:    0x100af4000
Identifier:      com.qvacua.VimR
Version:         0.58.0 (20251013.211150)
Code Type:       ARM64
Platform:        macOS
Parent Process:  launchd [1]
Date/Time:       2025-10-21 16:14:20.348 +0800
Launch Time:     2025-10-21 16:09:14.376 +0800
OS Version:      macOS 15.3.2 (24D81)
Report Version:  7
Analysis Tool:   /usr/bin/sample
Physical footprint:         74.8M
Physical footprint (peak):  164.8M
Idle exit:                  untracked
Call graph:
856 Thread_136959114: Main Thread
+ 856 completeTaskWithClosure(swift::AsyncContext*, swift::SwiftError*)  (in libswift_Concurrency.dylib) + 1  [0x265e81035]
+   856 ???  (in VimR)  load address 0x100af4000 + 0xd259  [0x100b01259]
+     856 ???  (in VimR)  load address 0x100af4000 + 0x814ed  [0x100b754ed]
+       856 ???  (in VimR)  load address 0x100af4000 + 0x9b21  [0x100afdb21]
+         856 ???  (in VimR)  load address 0x100af4000 + 0x2cac9  [0x100b20ac9]
+           856 ???  (in VimR)  load address 0x100af4000 + 0x340ec  [0x100b280ec]
+             856 ???  (in VimR)  load address 0x100af4000 + 0xd188  [0x100b01188]
+               856 ???  (in VimR)  load address 0x100af4000 + 0x26b1c  [0x100b1ab1c]
+                 856 ???  (in VimR)  load address 0x100af4000 + 0xd188  [0x100b01188]
+                   856 ???  (in VimR)  load address 0x100af4000 + 0x5680  [0x100af9680]
+                     856 -[NSApplication terminate:]  (in AppKit) + 848  [0x18940a384]
+                       856 -[NSApplication _shouldTerminate]  (in AppKit) + 1168  [0x189417244]
+                         856 -[NSApplication(NSEventRouting) _nextEventMatchingEventMask:untilDate:inMode:dequeue:]  (in AppKit) + 688  [0x189b68c24]
+                           856 _DPSNextEvent  (in AppKit) + 660  [0x189202848]
+                             856 _BlockUntilNextEventMatchingListInModeWithFilter  (in HIToolbox) + 76  [0x190bff508]
+                               856 ReceiveNextEventCommon  (in HIToolbox) + 676  [0x190bff348]
+                                 856 RunCurrentEventLoopInMode  (in HIToolbox) + 292  [0x190bf9530]
+                                   856 CFRunLoopRunSpecific  (in CoreFoundation) + 588  [0x18568a734]
+                                     856 __CFRunLoopRun  (in CoreFoundation) + 1212  [0x18568b2ac]
+                                       856 __CFRunLoopServiceMachPort  (in CoreFoundation) + 160  [0x18568ca4c]
+                                         856 mach_msg  (in libsystem_kernel.dylib) + 24  [0x18556329c]
+                                           856 mach_msg_overwrite  (in libsystem_kernel.dylib) + 480  [0x18556baf8]
+                                             856 mach_msg2_internal  (in libsystem_kernel.dylib) + 80  [0x185575604]
+                                               856 mach_msg2_trap  (in libsystem_kernel.dylib) + 8  [0x185562f54]
856 Thread_136959124   DispatchQueue_7: com.apple.root.background-qos  (concurrent)
+ 856 start_wqthread  (in libsystem_pthread.dylib) + 8  [0x18559f0f0]
+   856 _pthread_wqthread  (in libsystem_pthread.dylib) + 228  [0x1855a039c]
+     856 _dispatch_worker_thread2  (in libdispatch.dylib) + 156  [0x185403cd8]
+       856 _dispatch_root_queue_drain  (in libdispatch.dylib) + 860  [0x1854036a0]
+         856 _dispatch_client_callout  (in libdispatch.dylib) + 20  [0x1853f15b4]
+           856 _dispatch_call_block_and_release  (in libdispatch.dylib) + 32  [0x1853ef854]
+             856 ???  (in VimR)  load address 0x100af4000 + 0x61668  [0x100b55668]
+               856 ???  (in VimR)  load address 0x100af4000 + 0x150f14  [0x100c44f14]
+                 856 __accept  (in libsystem_kernel.dylib) + 8  [0x18556b804]
856 Thread_136959125
+ 856 start_wqthread  (in libsystem_pthread.dylib) + 8  [0x18559f0f0]
+   856 _pthread_wqthread  (in libsystem_pthread.dylib) + 364  [0x1855a0424]
+     856 __workq_kernreturn  (in libsystem_kernel.dylib) + 8  [0x185564ba4]
856 Thread_136959144
+ 856 start_wqthread  (in libsystem_pthread.dylib) + 8  [0x18559f0f0]
+   856 _pthread_wqthread  (in libsystem_pthread.dylib) + 364  [0x1855a0424]
+     856 __workq_kernreturn  (in libsystem_kernel.dylib) + 8  [0x185564ba4]
856 Thread_136959151: com.apple.NSEventThread
856 thread_start  (in libsystem_pthread.dylib) + 8  [0x18559f0fc]
856 _pthread_start  (in libsystem_pthread.dylib) + 136  [0x1855a42e4]
856 _NSEventThread  (in AppKit) + 148  [0x189327278]
856 CFRunLoopRunSpecific  (in CoreFoundation) + 588  [0x18568a734]
856 __CFRunLoopRun  (in CoreFoundation) + 1212  [0x18568b2ac]
856 __CFRunLoopServiceMachPort  (in CoreFoundation) + 160  [0x18568ca4c]
856 mach_msg  (in libsystem_kernel.dylib) + 24  [0x18556329c]
856 mach_msg_overwrite  (in libsystem_kernel.dylib) + 480  [0x18556baf8]
856 mach_msg2_internal  (in libsystem_kernel.dylib) + 80  [0x185575604]
856 mach_msg2_trap  (in libsystem_kernel.dylib) + 8  [0x185562f54]
Total number in stack (recursive counted multiple, when >=5):
Sort by top of stack, same collapsed (when >= 5):
__workq_kernreturn  (in libsystem_kernel.dylib)        1712
mach_msg2_trap  (in libsystem_kernel.dylib)        1712
__accept  (in libsystem_kernel.dylib)        856

[brnt]

This issue is still present in 0.59.0.

I'm just leaving the on-window-close setting to "do nothing" and I can still cmd-Q to kill the remaining process after closing the last window. Not a deal breaker, but not optimal.