std: Don't pass overlapped handles to processes #38835
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This commit fixes a mistake introduced in rust-lang#31618 where overlapped handles were leaked to child processes on Windows. On Windows once a handle is in overlapped mode it should always have I/O executed with an instance of `OVERLAPPED`. Most child processes, however, are not prepared to have their stdio handles in overlapped mode as they don't use `OVERLAPPED` on reads/writes to the handle. Now we haven't had any odd behavior in Rust up to this point, and the original bug was introduced almost a year ago. I believe this is because it turns out that if you *don't* pass an `OVERLAPPED` then the system will [supply one for you][link]. In this case everything will go awry if you concurrently operate on the handle. In Rust, however, the stdio handles are always locked, and there's no way to not use them unlocked in libstd. Due to that change we've always had synchronized access to these handles, which means that Rust programs typically "just work". Conversely, though, this commit fixes the test case included, which exhibits behavior that other programs Rust spawns may attempt to execute. Namely, the stdio handles may be concurrently used and having them in overlapped mode wreaks havoc. [link]: https://blogs.msdn.microsoft.com/oldnewthing/20121012-00/?p=6343 Closes rust-lang#38811
|
r? @brson (rust_highfive has picked a reviewer for you, use r? to override) |
|
I'm also going to beta-nominate this issue due to it fixing a stable-to-stable regression, but if this rides the trains that also seems reasonable. For me if this passes the test suite I'd imagine it's ready to backport. |
alexcrichton
added
beta-nominated
brson
added
the
beta-accepted
|
@bors r+ |
|
📌 Commit 5148918 has been approved by |
nagisa
reviewed
Jan 5, 2017
| @@ -54,11 +79,16 @@ pub fn anon_pipe() -> io::Result<(AnonPipe, AnonPipe)> { | |||
| .encode_wide() | |||
| .chain(Some(0)) | |||
| .collect::<Vec<_>>(); | |||
| let mut flags = c::FILE_FLAG_FIRST_PIPE_INSTANCE | | |||
| c::FILE_FLAG_OVERLAPPED; | |||
There was a problem hiding this comment.
Indentation is weird here. I immediately assumed this was inside some conditional.
There was a problem hiding this comment.
I’d honestly prefer if it was written as such:
let access_flag = if ours_readable { PIPE_ACCESS_INBOUND } else { PIPE_ACCESS_OUTBOUND };
let handle = c::CreateNamedPipeW(wide_name.as_ptr(),
PIPE_1 |
PIPE_2 |
access_flags, ...
|
@bors: p=1 This is a backport |
|
⌛ Testing commit 5148918 with merge 309dcc9... |
|
💔 Test failed - status-travis |
@bors retry |
|
⌛ Testing commit 5148918 with merge 9429fdc... |
|
💔 Test failed - status-travis |
|
@bors: retry
* osx linker segfaulted
…On Fri, Jan 6, 2017 at 8:21 AM, bors ***@***.***> wrote:
💔 Test failed - status-travis
<https://travis-ci.org/rust-lang/rust/builds/189523760>
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#38835 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AAD95CFyt6ddDzgOqb_L7QJflUHtE4CAks5rPmoVgaJpZM4LbMY2>
.
|
bors
added a commit
that referenced
this pull request
Jan 6, 2017
std: Don't pass overlapped handles to processes This commit fixes a mistake introduced in #31618 where overlapped handles were leaked to child processes on Windows. On Windows once a handle is in overlapped mode it should always have I/O executed with an instance of `OVERLAPPED`. Most child processes, however, are not prepared to have their stdio handles in overlapped mode as they don't use `OVERLAPPED` on reads/writes to the handle. Now we haven't had any odd behavior in Rust up to this point, and the original bug was introduced almost a year ago. I believe this is because it turns out that if you *don't* pass an `OVERLAPPED` then the system will [supply one for you][link]. In this case everything will go awry if you concurrently operate on the handle. In Rust, however, the stdio handles are always locked, and there's no way to not use them unlocked in libstd. Due to that change we've always had synchronized access to these handles, which means that Rust programs typically "just work". Conversely, though, this commit fixes the test case included, which exhibits behavior that other programs Rust spawns may attempt to execute. Namely, the stdio handles may be concurrently used and having them in overlapped mode wreaks havoc. [link]: https://blogs.msdn.microsoft.com/oldnewthing/20121012-00/?p=6343 Closes #38811
|
☀️ Test successful - status-appveyor, status-travis |
alexcrichton
removed
the
beta-nominated
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This commit fixes a mistake introduced in #31618 where overlapped handles were
leaked to child processes on Windows. On Windows once a handle is in overlapped
mode it should always have I/O executed with an instance of
OVERLAPPED. Mostchild processes, however, are not prepared to have their stdio handles in
overlapped mode as they don't use
OVERLAPPEDon reads/writes to the handle.Now we haven't had any odd behavior in Rust up to this point, and the original
bug was introduced almost a year ago. I believe this is because it turns out
that if you don't pass an
OVERLAPPEDthen the system will supply one foryou. In this case everything will go awry if you concurrently operate on
the handle. In Rust, however, the stdio handles are always locked, and there's
no way to not use them unlocked in libstd. Due to that change we've always had
synchronized access to these handles, which means that Rust programs typically
"just work".
Conversely, though, this commit fixes the test case included, which exhibits
behavior that other programs Rust spawns may attempt to execute. Namely, the
stdio handles may be concurrently used and having them in overlapped mode wreaks
havoc.
Closes #38811