mirror of
https://github.com/apple/container.git
synced 2026-08-24 10:05:43 -05:00
b73933eb2d
## Type of Change - [x] Bug fix - [ ] New feature - [ ] Breaking change - [ ] Documentation update ## Motivation and Context `CLITest.run(arguments:stdin:currentDirectory:env:)` reads stdout to EOF before stderr begins draining (`Tests/CLITests/Utilities/CLITest.swift:182-183`). If a child process writes more than a pipe-buffer's worth of data to stderr (~64 KB on macOS), the child blocks in `write()` on stderr while we block in `readDataToEndOfFile()` on stdout, and neither side makes progress until `process.waitUntilExit()` returns. This is a latent deadlock that any future test or CLI verbosity bump can trigger. This PR drains both streams concurrently using `readabilityHandler` closures backed by `Mutex<Data>` buffers. After `process.waitUntilExit()` returns the handlers are cleared and `readDataToEndOfFile()` flushes any bytes the kernel buffered between the last handler invocation and exit. The error path also clears handlers so a failed `process.run()` does not leak callbacks. `Mutex` matches the locking primitive the file already uses for `commandSeq`. Fixes #1456 ## Testing - [x] Tested locally - [ ] Added/updated tests - [ ] Added/updated docs `swift build --target CLITests` passes against the change. `make swift-fmt-check` is clean. Behavior is unchanged for any test command that previously fit within a single pipe buffer, so the existing CLITests still exercise the helper end-to-end. I did not add a new test that emits >64 KB to stderr because every existing CLITest invocation goes through `executablePath` (the `container` binary), and reproducing the deadlock requires a child that emits a controllable amount on stderr. Happy to follow up with a small refactor that extracts the drain into a static helper plus a regression test that drives it via `/bin/sh` if that would be useful. --------- Signed-off-by: Matt Van Horn <455140+mvanhorn@users.noreply.github.com> Co-authored-by: Matt Van Horn <455140+mvanhorn@users.noreply.github.com>