-
Notifications
You must be signed in to change notification settings - Fork 12.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Writing a sufficiently large string to a git bash pipe on windows regressed in 1.62 #98947
Comments
@ChrisDenton, I believe this must be because git bash (cygwin? msys?) is opening pipes between processes with In my original bug report, I suggested calling However, it seems that this got missed from the actual change (sorry, I should have caught that). Is there a reason this was skipped? |
Oh, hrm. That looks like an oversight on my part. I'll PR a fix asap. |
Thanks for fixing the issue quickly. 😀 When the PR that fixes this issue is merged, will a patch release 1.62.1 be published? 🙏 Or will we have to wait for a fix in 1.63? |
PR #98950 was nominated and accepted for both beta and stable backport by T-libs. |
Reproduction steps:
cargo new --bin something
cargo run | cat
I expected to see this happen: my really long string gets printed twice, followed by a clean exit
Instead, this happened: some amount of my really long string gets printed, followed by:
fatal runtime error: I/O error: operation failed to complete synchronously
Additional Details
cat
in the steps for simplicity, but we've observed this happening with other programs at the end of the pipe too.cargo run
is not necessary to trigger the crash, running the built executable directly also crashes.File
methods #95469rustc -C help
panics (ICEs) when piped to a closed stdout #98700 (comment)Version it worked on
Version with regression
@rustbot modify labels: +regression-from-stable-to-stable +O-windows
The text was updated successfully, but these errors were encountered: