std: Don't pass overlapped handles to processes by alexcrichton · Pull Request #38835 · rust-lang/rust

alexcrichton · 2017-01-04T23:46:31Z

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. 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

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=6343Closesrust-lang#38811

rust-highfive · 2017-01-04T23:46:42Z

r? @brson

(rust_highfive has picked a reviewer for you, use r? to override)

alexcrichton · 2017-01-04T23:47:47Z

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.

brson · 2017-01-05T00:12:12Z

@bors r+

bors · 2017-01-05T00:12:13Z

📌 Commit 5148918 has been approved by brson

nagisa · 2017-01-05T05:19:06Z

 .chain(Some(0))
 .collect::<Vec<_>>();
+ let mut flags = c::FILE_FLAG_FIRST_PIPE_INSTANCE |
+ c::FILE_FLAG_OVERLAPPED;


Indentation is weird here. I immediately assumed this was inside some conditional.

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, ...

alexcrichton · 2017-01-06T01:44:54Z

@bors: p=1

This is a backport

bors · 2017-01-06T11:44:09Z

⌛ Testing commit 5148918 with merge 309dcc9...

bors · 2017-01-06T11:47:41Z

💔 Test failed - status-travis

arielb1 · 2017-01-06T13:48:26Z

The command "if [ "$ALLOW_PR" = "" ] && [ "$TRAVIS_BRANCH" != "auto" ]; then
echo skipping, not a full build;
elif [ "$TRAVIS_OS_NAME" = "osx" ]; then
git submodule update --init &&
src/ci/run.sh;
else
git submodule update --init &&
src/ci/docker/run.sh $IMAGE;
fi
" exited with 129.

@bors retry

bors · 2017-01-06T14:53:22Z

⌛ Testing commit 5148918 with merge 9429fdc...

bors · 2017-01-06T16:21:39Z

💔 Test failed - status-travis

alexcrichton · 2017-01-06T17:02:27Z

@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 · 2017-01-06T23:49:35Z

⌛ Testing commit 5148918 with merge 7e38a89...

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=6343Closes#38811

bors · 2017-01-07T02:01:21Z

☀️ Test successful - status-appveyor, status-travis
Approved by: brson
Pushing 7e38a89 to master...

rust-highfive assigned brson Jan 4, 2017

alexcrichton added beta-nominated Nominated for backporting to the compiler in the beta channel. T-libs-api [DEPRECATED; DO NOT USE] labels Jan 4, 2017

dherman mentioned this pull request Jan 5, 2017
Windows npm issues neon-bindings/neon#159
Merged

brson added the beta-accepted Accepted for backporting to the compiler in the beta channel. label Jan 5, 2017

nagisa reviewed Jan 5, 2017
View reviewed changes

dherman mentioned this pull request Jan 5, 2017
more targeted workaround for Windows Command bug neon-bindings/neon#162
Closed

nikomatsakis mentioned this pull request Jan 6, 2017
Beta backports #38872
Merged
17 tasks

nikomatsakis mentioned this pull request Jan 6, 2017
More beta backports #38884
Merged
6 tasks

bors merged commit 5148918 into rust-lang:masterJan 7, 2017

alexcrichton deleted the less-overlapped branch January 7, 2017 05:44

alexcrichton removed the beta-nominated Nominated for backporting to the compiler in the beta channel. label Jan 7, 2017

m-ou-se mentioned this pull request Apr 13, 2022
Windows: Use a pipe relay for chaining pipes #95841
Merged

Uh oh!

Uh oh!

Conversation

alexcrichton commented Jan 4, 2017

Uh oh!

rust-highfive commented Jan 4, 2017

Uh oh!

alexcrichton commented Jan 4, 2017

Uh oh!

brson commented Jan 5, 2017

Uh oh!

bors commented Jan 5, 2017

Uh oh!

nagisaJan 5, 2017

Choose a reason for hiding this comment

Uh oh!

nagisaJan 5, 2017• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

alexcrichton commented Jan 6, 2017

Uh oh!

bors commented Jan 6, 2017

Uh oh!

bors commented Jan 6, 2017

Uh oh!

arielb1 commented Jan 6, 2017

Uh oh!

bors commented Jan 6, 2017

Uh oh!

bors commented Jan 6, 2017

Uh oh!

alexcrichton commented Jan 6, 2017 via email

Uh oh!

bors commented Jan 6, 2017

Uh oh!

bors commented Jan 7, 2017

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

6 participants

nagisaJan 5, 2017•
edited
Loading