Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

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

Abierto
  • ¿Algo no está bien?
#1,760 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
3/5
Tiempo estimado
1-2 días
Aptitud para principiantes
58/100
Tipo de issue
Error
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
macos, swift
Área
devtools

Línea de trabajo

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.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

fixed-in-next-release 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
Lenguaje dominante
Sin datos de lenguaje
Estrellas
123
Forks
1
Sin PR fusionados en 30 d

Preparar el entorno

Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de beyondcode/herd-community

Todos los issues de beyondcode/herd-community

Issues similares

Más issues de DevTools

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.