Memory-leak / NULL-safety fixes available on a fork branch (fork PRs are restricted)
Author: danalytisCreated May 18, 2026Updated Aug 26, 2026
Labelsbugaddressed on master; not released
bug, performance
I have three self-contained fixes for sources of gradual memory growth and occasional crashes during long-running operation, but this repo restricts pull requests to collaborators, so I can't open the PR directly. The branch is ready on my fork:
https://github.com/danalytis/yabai/tree/fix/memory-leaks(commit71fd788)Summary of the three fixes:
- event_loop autorelease-pool starvation — the pool in
event_loop_runis drained only on the empty-queue path; under sustained activity the inner loop never exits, so autoreleased SLS/CG/AX objects accumulate until yabai becomes unresponsive. Fix: pool per event. (Highest-impact; explains the common "degrades after running 24/7" reports.)- per-space view leak —
view_destroyonlymemsetsview->rootwhile every callerfrees the view struct immediately after, orphaning onewindow_nodeand theview->uuidCFString per space destroy.- NULL / uninitialised CF/AX derefs — missing NULL checks on
SLSCopyManagedDisplaySpaces(6 sites) andSLSCopyAssociatedWindows, plus an uninitialisedrolederef indisplay_manager_find_element_at_point. The sibling routines indisplay.calready guard the identical SLS call.Validated with a ~90-hour ASan-instrumented run: no ASan reports, no crashes, FD count flat. Fixes #1 and #2 are also verifiable by inspection.
Happy to open this as a proper PR if you can grant collaborator access, or to split it into three smaller PRs / cherry-pick whichever you want. Full per-fix rationale and diffs available.
Source: asmvik/yabai