std: Synchronize access to global env during exec
#55939
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
|
r? @sfackler |
sfackler
reviewed
Nov 13, 2018
src/test/run-pass/command-exec.rs
Outdated
| @@ -84,4 +94,14 @@ fn main() { | |||
| assert!(output.status.success()); | |||
| assert!(output.stderr.is_empty()); | |||
| assert_eq!(output.stdout, b"passed\n"); | |||
|
|
|||
| let output = Command::new(&me).arg("exec-test6").output().unwrap(); | |||
There was a problem hiding this comment.
Are exec-test6 and exec-test7 identical?
There was a problem hiding this comment.
I think morally yeah, they're just testing the two routes you can get at removing PATH from env (either by clearing or singularly removing it)
There was a problem hiding this comment.
Oh I missed the path manipulation up above.
|
It's unfortunate we can't use execvpe for this. We could potentially use it if supported and the command hasn't overridden PATH? Doesn't seem like we need to block this on that though. |
|
I think even with |
|
Multithreaded exec considered harmful :( @bors r+ |
|
📌 Commit b967d55 has been approved by |
bors
added
the
S-waiting-on-bors
|
💡 This pull request was already approved, no need to approve it again.
|
|
📌 Commit b967d55 has been approved by |
|
@bors: p=5 we'll need to backport this to fix the beta-regression as well |
alexcrichton
added
beta-nominated
bors
added a commit
that referenced
this pull request
Nov 14, 2018
std: Synchronize access to global env during `exec` This commit, after reverting #55359, applies a different fix for #46775 while also fixing #55775. The basic idea was to go back to pre-#55359 libstd, and then fix #46775 in a way that doesn't expose #55775. The issue described in #46775 boils down to two problems: * First, the global environment is reset during `exec` but, but if the `exec` call fails then the global environment was a dangling pointer into free'd memory as the block of memory was deallocated when `Command` is dropped. This is fixed in this commit by installing a `Drop` stack object which ensures that the `environ` pointer is preserved on a failing `exec`. * Second, the global environment was accessed in an unsynchronized fashion during `exec`. This was fixed by ensuring that the Rust-specific environment lock is acquired for these system-level operations. Thanks to Alex Gaynor for pioneering the solution here! Closes #55775
|
The job Click to expand the log.I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact |
|
💔 Test failed - status-travis |
bors
added
S-waiting-on-review
|
The job Click to expand the log.I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact |
kennytm
added
S-waiting-on-author
alexcrichton
force-pushed
the
path-regression-again
branch
from
b967d55
to
95585f4
Compare
|
@bors: r=sfackler |
|
📌 Commit 95585f473bdaa52a23a5208ed579c7cd368c32dd has been approved by |
bors
added
S-waiting-on-bors
|
@bors p=83 rollup fairness |
|
⌛ Testing commit 95585f473bdaa52a23a5208ed579c7cd368c32dd with merge d3cdb683b627cfb0e429984b501684c5dc42569e... |
bors
added
the
S-waiting-on-review
…nt in Command::exec" This reverts commit 36fe3b6.
|
@bors: retry |
bors
added
S-waiting-on-bors
|
⌛ Testing commit 95585f473bdaa52a23a5208ed579c7cd368c32dd with merge 07f40653dfbc70d4579010a1f73a8bd3a1af3fce... |
|
💔 Test failed - status-travis |
|
The job Click to expand the log.I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact |
bors
added
S-waiting-on-review
|
🤔 Any chance this change causes dead-lock during doc tests? |
|
Yes this seems non spurious, I will investigate |
|
Oh right, if a process forks with the lock held in one thread we can't then try to acquire it later. This will.need to acquire the lock before the fork |
This commit, after reverting rust-lang#55359, applies a different fix for rust-lang#46775 while also fixing rust-lang#55775. The basic idea was to go back to pre-rust-lang#55359 libstd, and then fix rust-lang#46775 in a way that doesn't expose rust-lang#55775. The issue described in rust-lang#46775 boils down to two problems: * First, the global environment is reset during `exec` but, but if the `exec` call fails then the global environment was a dangling pointer into free'd memory as the block of memory was deallocated when `Command` is dropped. This is fixed in this commit by installing a `Drop` stack object which ensures that the `environ` pointer is preserved on a failing `exec`. * Second, the global environment was accessed in an unsynchronized fashion during `exec`. This was fixed by ensuring that the Rust-specific environment lock is acquired for these system-level operations. Thanks to Alex Gaynor for pioneering the solution here! Closes rust-lang#55775 Co-authored-by: Alex Gaynor <[email protected]>
alexcrichton
force-pushed
the
path-regression-again
branch
from
95585f4
to
4032b7a
Compare
|
@bors: r=sfackler |
|
📌 Commit 4032b7a has been approved by |
bors
added
S-waiting-on-bors
bors
added a commit
that referenced
this pull request
Nov 14, 2018
std: Synchronize access to global env during `exec` This commit, after reverting #55359, applies a different fix for #46775 while also fixing #55775. The basic idea was to go back to pre-#55359 libstd, and then fix #46775 in a way that doesn't expose #55775. The issue described in #46775 boils down to two problems: * First, the global environment is reset during `exec` but, but if the `exec` call fails then the global environment was a dangling pointer into free'd memory as the block of memory was deallocated when `Command` is dropped. This is fixed in this commit by installing a `Drop` stack object which ensures that the `environ` pointer is preserved on a failing `exec`. * Second, the global environment was accessed in an unsynchronized fashion during `exec`. This was fixed by ensuring that the Rust-specific environment lock is acquired for these system-level operations. Thanks to Alex Gaynor for pioneering the solution here! Closes #55775
|
☀️ Test successful - status-appveyor, status-travis |
bors
added a commit
that referenced
this pull request
Nov 15, 2018
[beta] std: Synchronize access to global env during `exec` This is a beta backport of #55939
pietroalbini
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, after reverting #55359, applies a different fix for #46775
while also fixing #55775. The basic idea was to go back to pre-#55359
libstd, and then fix #46775 in a way that doesn't expose #55775.
The issue described in #46775 boils down to two problems:
First, the global environment is reset during
execbut, but if theexeccall fails then the global environment was a dangling pointerinto free'd memory as the block of memory was deallocated when
Commandis dropped. This is fixed in this commit by installing aDropstack object which ensures that theenvironpointer ispreserved on a failing
exec.Second, the global environment was accessed in an unsynchronized
fashion during
exec. This was fixed by ensuring that theRust-specific environment lock is acquired for these system-level
operations.
Thanks to Alex Gaynor for pioneering the solution here!
Closes #55775