[BUG] stream_read() can deadlock when captured output exceeds pipe buffer

[lucocozz]

Summary

stream_read() uses a self-pipe with no concurrent reader, so capturing more output than the pipe buffer (~64 KB on Linux) can deadlock the writing process.

Location

source/utils/stream.c — stream_redirect() / stream_read().

Mechanism

stream_redirect() replaces stdout/stderr with the write end of a pipe and only sets the read end non-blocking. The same single-threaded process both writes (via the redirected fd, blocking) and later drains it in stream_read(). If the program writes more than the pipe capacity before stream_read() is called, the blocking write() fills the pipe and blocks forever — nothing is draining it yet.

Impact

Edge case for this library: captured help/error text rarely exceeds 64 KB, so it is unlikely to bite in practice. Worth documenting as a known limit of the capture utility, or fixing if large captures are ever expected.

Suggested fix (if needed)

• Drain the pipe incrementally while the producer runs (thread / poll loop), or
• Document the maximum safely-capturable size and the blocking behavior.

Severity

Low — known limitation rather than a routinely-hit bug.