Fix abort-on-eprintln during process shutdown #69955
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 (rust_highfive has picked a reviewer for you, use r? to override) |
rust-highfive
added
the
S-waiting-on-review
alexcrichton
commented
Mar 12, 2020
| @@ -70,7 +75,7 @@ impl<T> ReentrantMutex<T> { | |||
| /// If another user of this mutex panicked while holding the mutex, then | |||
| /// this call will return failure if the mutex would otherwise be | |||
| /// acquired. | |||
| pub fn lock(&self) -> LockResult<ReentrantMutexGuard<'_, T>> { | |||
| pub fn lock(&self) -> ReentrantMutexGuard<'_, T> { | |||
There was a problem hiding this comment.
I removed the poisioning here since this type is only used for one thing in libstd, I/O handles, which ignore poisoning anyway.
|
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 |
alexcrichton
force-pushed
the
stderr-infallible
branch
from
77a63c8 to
f47f508
Compare
|
It sounds like this might be at least related to #69558 as well, though it's a slightly different problem based on a brief skim. |
|
Ah looks like that's unrelated, but still a pretty easy fix |
alexcrichton
force-pushed
the
stderr-infallible
branch
from
f47f508 to
3013d5b
Compare
sfackler
reviewed
Mar 12, 2020
| pub unsafe fn init(&mut self) { | ||
| self.lock = UnsafeCell::new(MaybeUninit::new(AtomicU32::new(abi::LOCK_UNLOCKED.0))); | ||
| self.recursion = UnsafeCell::new(MaybeUninit::new(0)); | ||
| pub unsafe fn init(&self) { |
There was a problem hiding this comment.
Not necessarily related to this PR, but why is this split out to a separate method in the first place? It seems like the lock's constructor would still be able to be const without needing to go through an uninitialized stage, right?
EDIT: Nevermind, it's platform specific!
|
@bors r+ |
|
📌 Commit 3013d5b6fcd0fda9278440deaa04a546e5076bfc has been approved by |
bors
added
S-waiting-on-bors
|
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 |
alexcrichton
force-pushed
the
stderr-infallible
branch
from
3013d5b to
4e00b6d
Compare
|
@bors: r=sfackler |
|
📌 Commit 4e00b6d34236feb0fd804cc250a10bb49c493e77 has been approved by |
|
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 |
alexcrichton
force-pushed
the
stderr-infallible
branch
from
4e00b6d to
8c734a5
Compare
|
@bors: r=sfackler |
|
📌 Commit 8c734a51ac17b4638b0e6e7b7b60a05bf00dd9c1 has been approved by |
|
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 |
alexcrichton
force-pushed
the
stderr-infallible
branch
from
8c734a5 to
c274e07
Compare
|
@bors: r=sfackler |
|
📌 Commit c274e07 has been approved by |
Dylan-DPC-zz
pushed a commit
to Dylan-DPC-zz/rust
that referenced
this pull request
Mar 14, 2020
…fackler Fix abort-on-eprintln during process shutdown This commit fixes an issue where if `eprintln!` is used in a TLS destructor it can accidentally cause the process to abort. TLS destructors are executed after `main` returns on the main thread, and at this point we've also deinitialized global `Lazy` values like those which store the `Stderr` and `Stdout` internals. This means that despite handling TLS not being accessible in `eprintln!`, we will fail due to not being able to call `stderr()`. This means that we'll double-panic quickly because panicking also attempt to write to stderr. The fix here is to reimplement the global stderr handle to avoid the need for destruction. This avoids the need for `Lazy` as well as the hidden panic inside of the `stderr` function. Overall this should improve the robustness of printing errors and/or panics in weird situations, since the `stderr` accessor should be infallible in more situations.
|
📌 Commit a4cbcb2 has been approved by |
|
🌲 The tree is currently closed for pull requests below priority 1000, this pull request will be tested once the tree is reopened |
Manishearth
added a commit
to Manishearth/rust
that referenced
this pull request
Mar 17, 2020
…fackler Fix abort-on-eprintln during process shutdown This commit fixes an issue where if `eprintln!` is used in a TLS destructor it can accidentally cause the process to abort. TLS destructors are executed after `main` returns on the main thread, and at this point we've also deinitialized global `Lazy` values like those which store the `Stderr` and `Stdout` internals. This means that despite handling TLS not being accessible in `eprintln!`, we will fail due to not being able to call `stderr()`. This means that we'll double-panic quickly because panicking also attempt to write to stderr. The fix here is to reimplement the global stderr handle to avoid the need for destruction. This avoids the need for `Lazy` as well as the hidden panic inside of the `stderr` function. Overall this should improve the robustness of printing errors and/or panics in weird situations, since the `stderr` accessor should be infallible in more situations.
|
@bors r- |
bors
added
S-waiting-on-author
alexcrichton
force-pushed
the
stderr-infallible
branch
from
a4cbcb2 to
2c22da0
Compare
|
@bors: r=sfackler |
|
📌 Commit 2c22da0 has been approved by |
bors
added
S-waiting-on-bors
Centril
added a commit
to Centril/rust
that referenced
this pull request
Mar 19, 2020
…fackler Fix abort-on-eprintln during process shutdown This commit fixes an issue where if `eprintln!` is used in a TLS destructor it can accidentally cause the process to abort. TLS destructors are executed after `main` returns on the main thread, and at this point we've also deinitialized global `Lazy` values like those which store the `Stderr` and `Stdout` internals. This means that despite handling TLS not being accessible in `eprintln!`, we will fail due to not being able to call `stderr()`. This means that we'll double-panic quickly because panicking also attempt to write to stderr. The fix here is to reimplement the global stderr handle to avoid the need for destruction. This avoids the need for `Lazy` as well as the hidden panic inside of the `stderr` function. Overall this should improve the robustness of printing errors and/or panics in weird situations, since the `stderr` accessor should be infallible in more situations.
bors
added
S-waiting-on-author
This commit fixes an issue where if `eprintln!` is used in a TLS destructor it can accidentally cause the process to abort. TLS destructors are executed after `main` returns on the main thread, and at this point we've also deinitialized global `Lazy` values like those which store the `Stderr` and `Stdout` internals. This means that despite handling TLS not being accessible in `eprintln!`, we will fail due to not being able to call `stderr()`. This means that we'll double-panic quickly because panicking also attempt to write to stderr. The fix here is to reimplement the global stderr handle to avoid the need for destruction. This avoids the need for `Lazy` as well as the hidden panic inside of the `stderr` function. Overall this should improve the robustness of printing errors and/or panics in weird situations, since the `stderr` accessor should be infallible in more situations.
alexcrichton
force-pushed
the
stderr-infallible
branch
from
2c22da0 to
5edaa7e
Compare
|
@bors: r=sfackler |
|
📌 Commit 5edaa7e has been approved by |
bors
added
S-waiting-on-bors
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Mar 21, 2020
Rollup of 6 pull requests Successful merges: - rust-lang#69497 (Don't unwind when hitting the macro expansion recursion limit) - rust-lang#69901 (add #[rustc_layout(debug)]) - rust-lang#69910 (Avoid query type in generics) - rust-lang#69955 (Fix abort-on-eprintln during process shutdown) - rust-lang#70032 (put type params in front of const params in generics_of) - rust-lang#70119 (rustc: use LocalDefId instead of DefId in TypeckTables.) Failed merges: r? @ghost
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 an issue where if
eprintln!is used in a TLSdestructor it can accidentally cause the process to abort. TLS
destructors are executed after
mainreturns on the main thread, and atthis point we've also deinitialized global
Lazyvalues like thosewhich store the
StderrandStdoutinternals. This means that despitehandling TLS not being accessible in
eprintln!, we will fail due tonot being able to call
stderr(). This means that we'll double-panicquickly because panicking also attempt to write to stderr.
The fix here is to reimplement the global stderr handle to avoid the
need for destruction. This avoids the need for
Lazyas well as thehidden panic inside of the
stderrfunction.Overall this should improve the robustness of printing errors and/or
panics in weird situations, since the
stderraccessor should beinfallible in more situations.