Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

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

Đã đóng
  • Có gì không ổn?
#1,760 0 bình luận 0 reaction 0 người được giao Xem trên GitHub

Chưa có ai nhận issue này.

Đánh giá

Độ khó
3/5
Thời gian dự kiến
1-2 ngày
Mức phù hợp với người mới
58/100
Loại issue
Lỗi
Độ rõ ràng
Khá rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
macos, swift
Lĩnh vực
devtools

Hướng nghiên cứu

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.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

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
Ngôn ngữ chính
Không có dữ liệu ngôn ngữ
Star
124
Fork
1
Không có pull request nào được merge trong 30 ngày

Chuẩn bị môi trường

Dự án này không cung cấp dev container, Dockerfile hay hướng dẫn đóng góp, nên bạn cần tự thiết lập môi trường: hãy bắt đầu từ README và xem hướng dẫn đóng góp lần đầu của chúng tôi để biết các bước chung.

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của beyondcode/herd-community

Tất cả issue của beyondcode/herd-community

Issue tương tự

Thêm issue về DevTools

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.