-
Notifications
You must be signed in to change notification settings - Fork 13.6k
Open
Labels
A-panicArea: Panicking machineryArea: Panicking machineryC-bugCategory: This is a bug.Category: This is a bug.T-compilerRelevant to the compiler team, which will review and decide on the PR/issue.Relevant to the compiler team, which will review and decide on the PR/issue.T-libsRelevant to the library team, which will review and decide on the PR/issue.Relevant to the library team, which will review and decide on the PR/issue.
Description
Example and initial analysis by @correabuscar:
#![feature(panic_always_abort)]
use std::fmt::{Display, self};
struct MyStruct;
impl Display for MyStruct {
fn fmt(&self, _: &mut fmt::Formatter<'_>) -> fmt::Result {
panic!("this is bad: {}", MyStruct);
}
}
fn main() {
std::panic::always_abort();
println!("{}", MyStruct);
}
The reason for this is that if both "panic while processing panic" and "panic after always_abort
" apply, then we use the AlwaysAbort
code path which does format the panic message.
This could be fixed by moving this check further down below the in_panic_hook
check:
rust/library/std/src/panicking.rs
Lines 393 to 395 in 9f25a04
if global_count & ALWAYS_ABORT_FLAG != 0 { | |
return Some(MustAbort::AlwaysAbort); | |
} |
But I don't know if this has other adverse side-effects. Can we even access thread-local variables after fork
(i.e., when always-abort is set)?
Cc @Amanieu
correabuscar
Metadata
Metadata
Assignees
Labels
A-panicArea: Panicking machineryArea: Panicking machineryC-bugCategory: This is a bug.Category: This is a bug.T-compilerRelevant to the compiler team, which will review and decide on the PR/issue.Relevant to the compiler team, which will review and decide on the PR/issue.T-libsRelevant to the library team, which will review and decide on the PR/issue.Relevant to the library team, which will review and decide on the PR/issue.