Hacktoberfest 2026:メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

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

オープン
#1,760 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

まだ誰も着手していません。

評価

難易度
3/5
見積もり時間
1〜2日
初心者へのやさしさ
58/100
issue の種類
バグ
明瞭さ
おおむね明確
活発さ
活発
技術スタック
macos, swift
領域
devtools

調査の方向性

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.

索引モデルが issue の本文から書いたものです。

説明

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
主要言語
言語のデータがありません
スター
123
フォーク
1
PR マージ指標
30日以内にマージされた PR はありません

環境構築

このプロジェクトには開発コンテナ、Dockerfile、コントリビューションガイドがありません。まず README を読み、一般的な手順ははじめてのコントリビューションガイドを参照してください。

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

beyondcode/herd-community のほかの issue

beyondcode/herd-community の issue をすべて見る

似ている issue

DevTools の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。