Memory-leak / NULL-safety fixes available on a fork branch (fork PRs are restricted)
- Dominant language
- C
- Stars
- 29.6k
- Forks
- 750
- PR merge metrics
- No merged PRs in 30d
Description
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 leak** — `view_destroy` only `memset`s `view->root` while every
> caller `free`s 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.
Contributor guide
No contributing guide indexed for this repository
Research direction
Start by reviewing commit 71fd788 on the linked fork branch and its per-fix rationale. Inspect event_loop_run, view_destroy, the SLSCopyManagedDisplaySpaces and SLSCopyAssociatedWindows call sites, display_manager_find_element_at_point, and the sibling guards in display.c. Done means the maintainers have selected or cherry-picked the fixes and the reported ASan, crash, and file-descriptor checks remain clean.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- c
- Domain
- desktop-dev, operating-systems
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 25/100