Whole-VM wedge: vCPU host thread stuck indefinitely in blocking open() during file-share op → guest CPU frozen → RCU stall (v2.2.1) #2593

Environment

• OrbStack: 2.2.1 (2020100), commit 0e182b5
• macOS: 26.5.1 (25F80), Mac16,10 (Apple M4, 16 GB)
• Guest kernel: 7.0.11-orbstack-00360-gc9bc4d96ac70 (arm64, 10 vCPUs)

Summary

Twice in two days the entire VM wedged: docker CLI commands hang indefinitely, all containers become unreachable, and vmgr sits at ~200% CPU. OrbStack's own hang sampler captured the root cause: one vCPU's host thread is blocked in a macOS open() syscall that never returns, so that guest CPU freezes mid-kernel and RCU never completes another grace period. The VM stays wedged for hours (~10h overnight in one case) until force-restarted.

Evidence

1. Host side (vmgr.sample.log, auto-captured by "sampling stacks due to VM hang")

vcpu1's thread was in the same blocking open() in 697 of 697 samples. Every other vCPU thread was in Hv::Vcpu::run() as normal:

697 Thread_26442668: vcpu1
+ 697 thread_start  (in libsystem_pthread.dylib) + 8
+   697 _pthread_start  (in libsystem_pthread.dylib) + 136
+     697 ???  (in OrbStack Helper)  load address 0x102500000 + 0x1b323ac
+       697 ???  (in OrbStack Helper)  load address 0x102500000 + 0x1818b30
+         697 ???  (in OrbStack Helper)  load address 0x102500000 + 0x1817580
+           697 ???  (in OrbStack Helper)  load address 0x102500000 + 0x17fedf0
+             697 ???  (in OrbStack Helper)  load address 0x102500000 + 0x19340f0
+               697 ???  (in OrbStack Helper)  load address 0x102500000 + 0x192fe30
+                 697 ???  (in OrbStack Helper)  load address 0x102500000 + 0x19c0aa0
+                   697 ???  (in OrbStack Helper)  load address 0x102500000 + 0x1867c24
+                     697 ???  (in OrbStack Helper)  load address 0x102500000 + 0x1872764
+                       697 open  (in libsystem_kernel.dylib) + 64
+                         697 __open  (in libsystem_kernel.dylib) + 8

697 Thread_26442669: vcpu2
+ ...
+                 697 Hv::Vcpu::run()  (in Hypervisor) + 348
+                   697 hv_trap  (in Hypervisor) + 8

The sample was taken ~9 hours into the hang; the thread never left that open().

2. Guest side (vmgr.1.log)

Every RCU stall report all night blames CPU 1, stuck in the same grace period g=5141 from the first report (t=90004 jiffies) to the last (t>1,490,000 jiffies):

[ 1638.358644] rcu: INFO: rcu_sched detected stalls on CPUs/tasks:
[ 1638.358663] rcu:  1-...0: (23 ticks this GP) idle=043c/1/0x4000000000000000 softirq=2203/2205 fqs=2912
[ 1638.358683] rcu:  (detected by 0, t=90004 jiffies, g=5141, q=11171 ncpus=10)
...
[ 3038.697105] rcu: INFO: rcu_sched detected stalls on CPUs/tasks:
[ 3038.697159] rcu:  1-...0: (23 ticks this GP) idle=043c/1/0x4000000000000000 softirq=2203/2205 fqs=241090
[ 3038.697180] rcu:  (detected by 9, t=1490175 jiffies, g=5141, q=18069 ncpus=10)
[ 1648.396594] rcu: rcu_sched kthread starved for 10031 jiffies! g5141 f0x0 RCU_GP_DOING_FQS(6) ->state=0x0 ->cpu=2

CPU 1 never responds to NMI backtrace requests — Sending NMI from CPU 0 to CPUs 1: is followed by no backtrace for CPU 1 (consistent with the vCPU being blocked host-side, not executing guest code).

Workload at the moment of the hang

Both hangs began while a container was doing a recursive content search (grep-like tool of an AI coding agent) across a large bind-mounted macOS directory (dozens of code projects with node_modules etc.). In the captured case the agent's log stops at 11:16:12Z and the first RCU stall was detected at 11:17:43Z. So the likely path is: guest FUSE/virtiofs request → handled synchronously on the vCPU thread → host open() blocks forever on some pathological file.

I could not identify the specific file after restart — no FIFOs, sockets, or dataless/cloud-placeholder files remain in the tree — but a transient FIFO created inside the shared tree (e.g. by a container process) would explain an open() that blocks indefinitely (FIFO with no writer). Regardless of the specific file, servicing a guest file-share request with an unbounded blocking open() on the vCPU thread seems like the underlying defect (O_NONBLOCK + retry off-thread would avoid wedging the guest CPU).

Recovery behavior

• docker CLI: hangs
• orb restart docker: hangs
• orb stop + orb start: recovers (stop succeeded; start reported "timed out waiting for VM to start" but the VM did come up)

Repro

Not deterministic. Happened twice in ~24h under the workload above (recursive scans of a large shared tree); uneventful for months before that.

Happy to provide the full vmgr.1.log / vmgr.sample.log privately if useful.