Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

[Bug]: Privileged helper spins at 200% CPU: readabilityHandler is not cleared at EOF

Aperta
  • Qualcosa non va?
#1,760 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
3/5
Tempo stimato
1-2 giorni
Idoneità per principianti
58/100
Tipo di issue
Bug
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
macos, swift
Ambito
devtools

Direzione di ricerca

Start by locating MonitoredProcessManager and its readabilityHandler for the monitored process output pipe; the issue’s decompiled example identifies the EOF path to inspect. Verify the handler is cleared even when self is gone or outputPipe has changed, and add or run a relevant test if the project has one; done means EOF stops repeated handler calls without affecting a different pipe.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

macOS
Platform

macOS

Operating system version

macOS 26.6.2

System architecture

ARM64 (M1, M2, etc)

Herd Version

1.28.0

PHP Version

No response

Bug description

After long uptime (~34 days in my case), the privileged helper /Library/PrivilegedHelperTools/de.beyondco.herd.helper sat at a constant ~200% CPU (two full cores), heating the machine. Nothing in Herd's UI indicated a problem, and the helper did not write anything to the system log.

sudo launchctl kickstart -k system/de.beyondco.herd.helper fixed it immediately (CPU dropped to ~0%), and Herd services kept working. So the helper had been stuck in a busy loop, not doing useful work.

Helper binary: universal, sha256 f017ba852a28e939cf43cfcc2f269501165cc5276febea26b0355596639a000e.

Likely cause

I looked at the arm64 slice of the helper to find what could be spinning. In MonitoredProcessManager, the monitored process's output is read through outputPipe.fileHandleForReading.readabilityHandler (installed at 0x10001a118, handler body at 0x10001a220). Decompiled, the handler looks roughly like this:

pipe.fileHandleForReading.readabilityHandler = { [weak self] handle in
    let data = handle.availableData
    if !data.isEmpty {
        if let s = String(data: data, encoding: .utf8) {
            DispatchQueue.main.async { /* append to processLogs */ }
        }
    } else {
        guard let self, let pipe = self.outputPipe else { return }
        pipe.fileHandleForReading.readabilityHandler = nil
    }
}

At EOF, readabilityHandler is invoked repeatedly with empty data until it is set to nil, and each such handler pins one core. This handler clears itself through self.outputPipe, not through the handle it received, so it can stay installed forever:

  1. The owner is gone. weak self is nil, the guard returns, and the handler is never cleared.
  2. The owner now holds a different pipe. After a monitored process is restarted (for example, switching PHP versions or restarting services), outputPipe points to the new pipe. The old handler then clears the new pipe's handler and keeps spinning on its own.

Two stale handlers like this would account for exactly the 200% I saw.

Suggested fix

Clear the handler through the handle passed into the closure, which does not depend on self or on which pipe is current:

} else {
    handle.readabilityHandler = nil
}
Caveat

I did not reproduce the busy loop directly: the helper was already restarted when I analyzed it. The analysis above is based on reading the shipped binary, and it matches the observed symptoms (exactly two cores, long uptime, instant fix after restarting the helper).

Steps to reproduce

Not reliably reproducible on demand. Observed after ~34 days of uptime with Herd services (nginx, dnsmasq, PHP) running and being restarted / PHP versions switched over that period. The code path above suggests: restart or replace a monitored process while its previous output pipe hits EOF.

Relevant log output
$ ps -Ao pid,pcpu,etime,comm -r | head -2
  PID  %CPU     ELAPSED COMMAND
 5373 199.3 34-13:56:30 /Library/PrivilegedHelperTools/de.beyondco.herd.helper
Lingua principale
Nessun dato sulla lingua
Stelle
123
Fork
1
Nessuna PR unita negli ultimi 30g

Preparare l'ambiente

Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di beyondcode/herd-community

Tutte le issue di beyondcode/herd-community

Issue simili

Altre issue su DevTools

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.