std: Fix inheriting standard handles on windows by alexcrichton · Pull Request #24873 · rust-lang/rust

alexcrichton · 2015-04-27T21:44:24Z

Currently if a standard I/O handle is set to inherited on Windows, no action is
taken and the slot in the process information description is set to
INVALID_HANDLE_VALUE. Due to our passing of STARTF_USESTDHANDLES, however,
this means that the handle is actually set to nothing and if a child tries to
print it will generate an error.

This commit fixes this behavior by explicitly creating stdio handles to be
placed in these slots by duplicating the current process's I/O handles. This is
presumably what previously happened silently by using a file-descriptor-based
implementation instead of a HANDLE-centric implementation.

Along the way this cleans up a lot of code in Process::spawn for Windows by
ensuring destructors are always run, using more RAII, and limiting the scope of
unsafe wherever possible.

rust-highfive · 2015-04-27T21:44:28Z

r? @pcwalton

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

alexcrichton · 2015-04-27T21:46:08Z

r? @aturon

Also nominating for beta cherry-pick.

tamird · 2015-04-27T21:55:27Z

can this be an inner function rather than a closure?
by the way, what are the implications of using a closure (which doesn't close over anything) over an inner function?

Oh wow I guess this doesn't close over anything any more (it did previously). If you're not closing over anything then I'd recommend a free function personally as you probably need to have type annotations anyway.

tamird · 2015-04-27T22:05:33Z

why return _data here?

aturon · 2015-04-27T22:10:05Z

Oy, fun bug :)

This PR LGTM. Cute use of "RAII".

aturon · 2015-04-27T22:13:20Z

@tamird The reason to return _data is that it's holding ownership of the actual data that the raw pointer is pointing to (in the case that it's not null). The data itself is only being used via the pointer (which is passed down to C), but you want to keep the vector alive for the duration of the function to keep that data allocated. This is a somewhat subtle use of an RAII-ish pattern.

alexcrichton · 2015-04-27T22:17:24Z

@bors: r=aturon cb41b82

tamird · 2015-04-27T22:17:24Z

@aturon cool, that's what I suspected, thanks. Allocating an empty vector in the None case strikes me as odd though; is there an owning pointer type that can be used to express this pattern without the extra allocation?

alexcrichton · 2015-04-27T22:24:01Z

It's possible that it could just return a Vec<T> and then .as_ptr() could be used as necessary, but this is just mirroring what unix does for now.

bors · 2015-04-28T08:40:19Z

⌛ Testing commit cb41b82 with merge f20b8e8...

bors · 2015-04-28T08:43:14Z

💔 Test failed - auto-win-32-opt

alexcrichton · 2015-04-28T16:38:00Z

@bors: retry

On Tue, Apr 28, 2015 at 1:43 AM, bors notifications@github.com wrote:

[image: 💔] Test failed - auto-win-32-opt
http://buildbot.rust-lang.org/builders/auto-win-32-opt/builds/4389
—
Reply to this email directly or view it on GitHub
#24873 (comment).

bors · 2015-04-29T07:22:03Z

⌛ Testing commit cb41b82 with merge 99f628b...

bors · 2015-04-29T07:37:57Z

💔 Test failed - auto-win-64-nopt-t

Currently if a standard I/O handle is set to inherited on Windows, no action is taken and the slot in the process information description is set to `INVALID_HANDLE_VALUE`. Due to our passing of `STARTF_USESTDHANDLES`, however, this means that the handle is actually set to nothing and if a child tries to print it will generate an error. This commit fixes this behavior by explicitly creating stdio handles to be placed in these slots by duplicating the current process's I/O handles. This is presumably what previously happened silently by using a file-descriptor-based implementation instead of a `HANDLE`-centric implementation. Along the way this cleans up a lot of code in `Process::spawn` for Windows by ensuring destructors are always run, using more RAII, and limiting the scope of `unsafe` wherever possible.

alexcrichton · 2015-04-29T15:02:34Z

@bors: r=aturon c1149ed

Conflicts: src/libstd/sys/windows/fs2.rs

pnkfelix · 2015-04-30T21:19:33Z

triage: beta-accepted

(as a special case for the 1.0 release; post 1.0 changes like this probably would not be accepted for backport)

brson · 2015-04-30T22:17:39Z

Backported.

rust-highfive assigned pcwalton Apr 27, 2015

alexcrichton force-pushed the fix-windows-stdio branch from fda3347 to 9761b00Compare April 27, 2015 21:45

rust-highfive assigned aturon and unassigned pcwalton Apr 27, 2015

alexcrichton added the beta-nominated Nominated for backporting to the compiler in the beta channel. label Apr 27, 2015

alexcrichton mentioned this pull request Apr 27, 2015
Loosen the dependency versions in Cargo.toml rust-lang/cargo#1551
Merged

tamird reviewed Apr 27, 2015
View reviewed changes

alexcrichton force-pushed the fix-windows-stdio branch 3 times, most recently from 7694ee7 to 1d8388eCompare April 27, 2015 22:00

tamird reviewed Apr 27, 2015
View reviewed changes

Comment threadsrc/libstd/sys/windows/process2.rs Outdated
tamirdApr 27, 2015
Copy link
Copy Markdown
Contributor
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
why return _data here?

alexcrichton force-pushed the fix-windows-stdio branch from 1d8388e to cb41b82Compare April 27, 2015 22:08

alexcrichton mentioned this pull request Apr 28, 2015
'Expect argument for flag' shows Debug instead of Display output rust-lang/cargo#1553
Closed

alexcrichton force-pushed the fix-windows-stdio branch from cb41b82 to c1149edCompare April 29, 2015 15:02

alexcrichton mentioned this pull request Apr 29, 2015
Output from gcc should be shown when the build fails rust-lang/cc-rs#36
Closed

alexcrichton added a commit to alexcrichton/rust that referenced this pull request Apr 29, 2015
rollup merge ofrust-lang#24873: alexcrichton/fix-windows-stdio
cc04cd4
Conflicts: src/libstd/sys/windows/fs2.rs

bors merged commit c1149ed into rust-lang:masterApr 30, 2015

alexcrichton deleted the fix-windows-stdio branch April 30, 2015 02:05

pnkfelix added the beta-accepted Accepted for backporting to the compiler in the beta channel. label Apr 30, 2015

alexcrichton mentioned this pull request Apr 30, 2015
Backport of PRs to Beta #25004
Merged

brson removed the beta-nominated Nominated for backporting to the compiler in the beta channel. label Apr 30, 2015

Uh oh!

Uh oh!

Conversation

alexcrichton commented Apr 27, 2015

Uh oh!

rust-highfive commented Apr 27, 2015

Uh oh!

alexcrichton commented Apr 27, 2015

Uh oh!

tamirdApr 27, 2015

Choose a reason for hiding this comment

Uh oh!

alexcrichtonApr 27, 2015

Choose a reason for hiding this comment

Uh oh!

tamirdApr 27, 2015

Choose a reason for hiding this comment

Uh oh!

aturon commented Apr 27, 2015

Uh oh!

aturon commented Apr 27, 2015

Uh oh!

alexcrichton commented Apr 27, 2015

Uh oh!

tamird commented Apr 27, 2015

Uh oh!

alexcrichton commented Apr 27, 2015

Uh oh!

bors commented Apr 28, 2015

Uh oh!

bors commented Apr 28, 2015

Uh oh!

alexcrichton commented Apr 28, 2015

Uh oh!

bors commented Apr 29, 2015

Uh oh!

bors commented Apr 29, 2015

Uh oh!

alexcrichton commented Apr 29, 2015

Uh oh!

pnkfelix commented Apr 30, 2015

Uh oh!

brson commented Apr 30, 2015

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

8 participants