Startup crash on Apple M4 / macOS 26.3: EXC_GUARD (DEALLOC_GAP) in HVF hv_vm_unmap

[RealForce1024]

Summary

Try Omarchy 0.4.0 (build 5) crashes during guest startup on an Apple M4 running macOS 26.3. The bundled QEMU process is terminated roughly 3.5 seconds after launch, before reaching a usable guest desktop.

The fresh macOS crash report matches the faulting call chain in two earlier local reports: a pflash write triggers a memory-map update, followed by hvf_set_phys_mem → hv_vm_unmap → EXC_GUARD / GUARD_TYPE_VIRT_MEMORY / DEALLOC_GAP.

Environment

• Try Omarchy: 0.4.0, CFBundleVersion 5 (installed app's Info.plist)
• Bundled QEMU: 11.1.1 (Contents/Resources/runtime/bin/Try Omarchy --version)
• Host: Apple M4, ARM64
• macOS: 26.3 (25D125)
• VM: existing persistent disk; launcher selected 8 vCPUs / 4 GiB RAM
• Bundled machine configuration: virt,accel=hvf,gic-version=3, CPU host,pmu=off

Reproduction

With no other Try Omarchy instance running, invoke the installed app's bundled launcher to capture stdout/stderr:

OMARCHY_QEMU_GPU_IMMERSIVE=0 \
  /bin/bash '/Applications/Try Omarchy.app/Contents/Resources/scripts/run-qemu-gpu.sh'

This uses the existing persistent VM without resetting it. No app files were modified. In this diagnostic reproduction, port forwarding and shared-folder export were not enabled.

Expected: The guest finishes booting and remains running.

Actual: The launcher reports [qemu-gpu] Ready., the guest proceeds through initramfs hooks and mounts its root disk, then macOS kills the QEMU process with signal 9. The launcher exits with status 137.

Startup output

User-specific path replaced with <HOME>:

[qemu-gpu] Starting the persistent ARM64 VirGL guest with 8 vCPUs and 4 GiB RAM.
[qemu-gpu] User data: <HOME>/Library/Application Support/Try Omarchy/VM/v1/disks/current
[qemu-gpu] Port forwarding: disabled
[qemu-gpu] Ready.
[camera-bridge] The Mac camera is available to Omarchy on demand.
[clipboard-bridge] The Mac clipboard is shared with Omarchy.
[audio-bridge] Host audio devices are available inside Omarchy.
:: running early hook [udev]
Starting systemd-udevd version 261.2-1-arch
GL strings: version='OpenGL ES 3.0 (ANGLE 2.1.26812 git hash: 2d91f554ab55)' renderer='ANGLE (Apple, ANGLE Metal Renderer: Apple M4, Version 26.3 (Build 25D125))' glsl='OpenGL ES GLSL ES 3.00 (ANGLE 2.1.26812 git hash: 2d91f554ab55)'
:: running hook [udev]
:: Triggering uevents...
:: running hook [keymap]
:: Loading keymap...kbd_mode: KDSKBMODE: Inappropriate ioctl for device
done.
:: performing fsck on '/dev/vda'
omarchy-factory: recovering journal
omarchy-factory: clean, 129917/1572864 files, 1286866/6291456 blocks
:: mounting '/dev/vda' on real root
:: running late hook [try-omarchy-boot-export]
:: running cleanup hook [udev]
/Applications/Try Omarchy.app/Contents/Resources/scripts/run-qemu-gpu.sh: line 1469: 12004 Killed: 9               "$qemu_bin" "${qemu_args[@]}"

macOS crash report excerpt

Exception type:    EXC_GUARD
Exception subtype: GUARD_TYPE_VIRT_MEMORY
Exception flavor:  DEALLOC_GAP
Exception message: offset=0x0000000000000000, flavor=0x00000001 (DEALLOC_GAP)
Termination:       namespace GUARD
Faulting thread:   */HVF

Faulting thread, top frame first:

hv_trap
Hv::Vm::unmap_space(unsigned long long, unsigned long long, unsigned long)
hv_vm_unmap
hvf_set_phys_mem
address_space_update_topology_pass
address_space_set_flatview
memory_region_transaction_commit
pflash_mem_write_with_attrs
access_with_adjusted_size
memory_region_dispatch_write
flatview_write_continue_step
flatview_write
address_space_write
hvf_arch_vcpu_exec
hvf_cpu_thread_fn
qemu_thread_start
_pthread_start
thread_start

The fresh report records launch at 12:38:18.2026 and crash at 12:38:21.6701 (approximately 3.47 seconds). Two earlier reports show the same HVF/pflash faulting call chain.

Scope of diagnosis

• The bundled launcher's code-signature checks passed and guest execution started; this is not a missing-symbol/dyld startup failure like the one discussed in Try Omarchy couldn't start #22.
• The guest filesystem check reported clean after journal recovery. The kbd_mode warning did not stop startup; execution continued beyond it.
• The stack localizes the failure to the pflash → HVF memory-unmapping path, but does not establish whether the underlying bug belongs to QEMU, an app-specific patch, or macOS Hypervisor.framework.
• No TCG comparison, clean/disposable VM comparison, macOS upgrade, or replacement QEMU runtime has been tested. No workaround is claimed.

Could you investigate the bundled runtime's HVF mapping/unmapping behavior on this host configuration? The excerpts above omit user identifiers and unrelated crash-report metadata.