Mac crashes while running MLX_ML model
Apple. Please fix well documented crash bug.
Yes—several other people are experiencing the exact same crash, down to this identical panic string:
"completeMemory() prepare count underflow" @IOGPUMemory.cpp:550
Public reports cover multiple Apple-silicon generations:
- An M4 Max user reproduced it twice during a roughly 173,000-token MLX prefill. Their kernel target was also RELEASE_ARM64_T6041, matching your log. The report was filed with Apple as ***.
- An M3 Ultra user recorded seven occurrences over March 31–April 1 during repeated large-model inference.
- An M2 Ultra user experienced four identical panics within about one hour after an oMLX update.
- An M1 Max user reported two full-machine reboots during concurrent coding-agent requests.
- An M2 Max user reproduced it three times, including once without any sleep/wake event—similar to your log, where Sleep and Wake are both zero.
- There is also an open report from a 16 GB M4 Mac mini running an MLX model.
- An EXO user reported the same panic on an M4 Max 128 GB machine during distributed inference.
Most importantly, this has not disappeared on macOS 26.5.2. A report opened July 17, 2026 used macOS 26.5.2 with MLX 0.32.0 on an M4 Mac and says the workload triggered the known IOGPUFamily panics—including this IOGPUMemory.cpp:550 signature—five times that day.
What the reports have in common
The public cases are heavily concentrated around Python applications using MLX and Metal for local AI inference, especially with:
- Long prompts or growing KV caches
- Concurrent inference requests
- Model loading and unloading
- Cache eviction or buffer cleanup
- Large amounts of wired unified memory
One report showed the Python process consuming about 83 GB on a 96 GB machine, much of it wired memory that macOS could not reclaim normally. Another controlled investigation reproduced the panic consistently with concurrent requests and cache-eviction activity, then avoided it in 20 test runs by preventing MLX from calling mx.set_wired_limit; that is an experimental third-party mitigation, not an official Apple fix.
So your crash is not isolated, and the spread across M1, M2, M3, and M4 systems argues against a uniquely defective CPU core or a fault specific to your individual Mac. The evidence points to an Apple IOGPUFamily driver bug whose trigger is exposed by certain MLX/Metal memory-management patterns. The Python application still matters because its allocation and cleanup behavior determines whether the driver bug gets hit.
[Edited by Moderator]
