darwin: fix leaked Process on first-seen thread when userland threads hidden

[eejd]

Summary

DarwinProcess_scanThreads() leaks one Process/DarwinProcess object per
never-before-seen thread, on every refresh cycle, whenever "Hide userland
process threads" (hide_userland_threads=1 in htoprc) is enabled.

bool preExisting;
Process *tprocess = ProcessTable_getProcess(&dpt->super, (pid_t)tid, &preExisting, DarwinProcess_new);
tprocess->super.updated = true;
dpt->super.totalTasks++;

if (hideUserlandThreads) {
   tprocess->super.show = false;
   continue;          // <-- leaves tprocess unregistered when !preExisting
}
...
if (!preExisting)
   ProcessTable_add(&dpt->super, tprocess);

When tid has never been seen before, ProcessTable_getProcess()
constructs a fresh object (xCalloc) but does not add it to the table --
that only happens at the bottom of the loop body, past the continue. The
object is then:

• never reachable via the hashtable/rows vector (so the next scan of the
  same tid allocates yet another new object), and
• never visited by Table_cleanupEntries() (so it's never freed via
  Process_delete/Process_done).

linux/LinuxProcessTable.c has the equivalent hide-branch but guards it
with preExisting &&, specifically so a thread is always registered on
first sight before being hidden on later scans:

if (preExisting && hideUserlandThreads && Process_isUserlandThread(proc)) {
   ...
   continue;
}

Darwin's version is missing that guard.

Fix

Minimal change, keeps the existing short-circuit structure -- just
registers the object before continuing:

if (hideUserlandThreads) {
   tprocess->super.show = false;
   if (!preExisting)
      ProcessTable_add(&dpt->super, tprocess);
   continue;
}

Impact / how this was found

On a host with heavy, sustained thread churn (a multi-agent workload host,
~3000 live system threads), this leaks continuously. Found via vmmap
diagnosis of a separate, unexplained ~2GB physical-footprint / ~3.3M-live-
allocation growth on a long-running htop instance -- that instance had
hide_userland_threads=0, so this bug wasn't the cause of that specific
growth, but is a real, independent leak, confirmed by code review and
reproduced by inspection of the code path (this fix has been soak-tested
locally via a MacPorts overlay build pinned to this branch).

Full write-up: eejd#2

Opening as draft while the local soak test runs longer to build confidence
before requesting review.

Assisted-by: Claude Sonnet 5 noreply@anthropic.com

[coderabbitai]

Navigate logical layers of code changes, visualize relationships, and explore their blast radius.

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Repository UI

Review profile: ASSERTIVE

Plan: Advanced

Run ID: 4afdb1a6-de80-4288-992a-eeffd88d3e8b

📥 Commits

Reviewing files that changed from the base of the PR and between 1daf6d9 and 808e7e7.

📒 Files selected for processing (1)

• darwin/DarwinProcess.c

Included review availability: Your plan provides up to 8 included reviews per hour; 7 remain after this review.

---

📝 Walkthrough

Walkthrough

When hideUserlandThreads is enabled, DarwinProcess_scanThreads now adds newly discovered threads to the process table before continuing. Pre-existing threads remain unadded by this branch.

Suggested reviewers: natoscott

Priority: ⬇️ Low

Change: Bug fix

Merge Risk: ⚪ Minimal · up to 808e7

Newly discovered hidden threads remain tracked and can be reclaimed when they disappear. No actionable merge-blocking risk is established; the change is ready for normal checks.

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Hidden threads join the table
Newly found, now counted
Then the scan moves on
Existing threads stay unchanged
A small branch completes its pass}

_{Comment @coderabbitai help to get the list of available commands.}

[eejd]

Independent code-reviewer disposition

Findings from the independent review:

• Correctness (leak fix, table-consistency, Table_add asserts): PASS, no issues.
• LOW — partial state on a first-sight hidden entry (zero-initialized parent/threadGroup/isUserlandThread/st_uid/user until the next visible scan): agreed this is benign given show=false, and is corrected on the next non-hidden scan. Deferring rather than changing scope here -- a fuller alignment with Linux's "always fully populate on first sight" approach would be a separate, larger change to this same function, not a fix-up of this 2-line patch.
• LOW — AI attribution ("Claude Sonnet 5"): reviewed and declined. This is correct as written -- confirmed against this session's own model identity and its explicit attribution convention for commit/PR trailers. The reviewer agent didn't have access to that context, so its claim doesn't hold up on independent verification.
• INFO items: no action needed, all noted as acceptable (no test infra in this codebase; commit message accuracy confirmed).

No code changes needed. This PR is otherwise ready for real review whenever the soak test has run long enough.

[eejd]

Closing -- opened prematurely without the fork owner's authorization to submit upstream yet. Apologies for the noise.