#2791·yabai

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 (commit 71fd788)

Summary of the three fixes:

  1. event_loop autorelease-pool starvation — the pool in event_loop_run is 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.)
  2. per-space view leakview_destroy only memsets view->root while every caller frees the view struct immediately after, orphaning one window_node and the view->uuid CFString per space destroy.
  3. NULL / uninitialised CF/AX derefs — missing NULL checks on SLSCopyManagedDisplaySpaces (6 sites) and SLSCopyAssociatedWindows, plus an uninitialised role deref in display_manager_find_element_at_point. The sibling routines in display.c already 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.