-
Notifications
You must be signed in to change notification settings - Fork 339
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Disable fault_handler
logging in release builds (MLLVD-CR-24-02)
#7137
Conversation
fault_handler
in release buildsfault_handler
logging in release builds
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Reviewed 1 of 1 files at r1, all commit messages.
Reviewable status: all files reviewed, 1 unresolved discussion (waiting on @hulthe)
mullvad-daemon/src/exception_logging/unix.rs
line 90 at r1 (raw file):
// NOTE: `process::abort` is safer than `process::exit` because it doesn't perform any cleanup #[cfg(not(debug_assertions))] std::process::abort();
Should we instead not register a signal handler at all when debug_assertions
is false? I.e. by conditionally compiling INIT_ONCE.call_once(...)
.
0a3cd46
to
000f570
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Reviewable status: 0 of 1 files reviewed, 1 unresolved discussion (waiting on @dlon)
mullvad-daemon/src/exception_logging/unix.rs
line 90 at r1 (raw file):
Previously, dlon (David Lönnhager) wrote…
Should we instead not register a signal handler at all when
debug_assertions
is false? I.e. by conditionally compilingINIT_ONCE.call_once(...)
.
Removed the signal handler completely. Also reworded some comments, lmk what you think.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Reviewed 1 of 1 files at r2, all commit messages.
Reviewable status: complete! all files reviewed, all discussions resolved
mullvad-daemon/src/exception_logging/unix.rs
line 90 at r1 (raw file):
Previously, hulthe (Joakim Hulthe) wrote…
Removed the signal handler completely. Also reworded some comments, lmk what you think.
Nit: Do you think it would be cleaner to move the code into a module and make only that mod conditional on debug_assertions
?
#[cfg(debug_assertions)]
mod inner {
pub fn enable() {
static INIT_ONCE: Once = Once::new();
// ...
}
}
#[cfg(not(debug_assertions))]
mod inner {
pub fn enable() {
// do nothing
}
}
// TODO: I'm bad at naming?
pub use inner::*;
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Reviewed all commit messages.
Reviewable status: complete! all files reviewed, all discussions resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Reviewable status: complete! all files reviewed, all discussions resolved
mullvad-daemon/src/exception_logging/unix.rs
line 90 at r1 (raw file):
Previously, dlon (David Lönnhager) wrote…
Nit: Do you think it would be cleaner to move the code into a module and make only that mod conditional on
debug_assertions
?#[cfg(debug_assertions)] mod inner { pub fn enable() { static INIT_ONCE: Once = Once::new(); // ... } } #[cfg(not(debug_assertions))] mod inner { pub fn enable() { // do nothing } } // TODO: I'm bad at naming? pub use inner::*;
Yes i would
000f570
to
99b1b31
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Reviewed 1 of 1 files at r3, all commit messages.
Reviewable status: complete! all files reviewed, all discussions resolved
99b1b31
to
d903147
Compare
fault_handler
logging in release buildsfault_handler
logging in release builds (MLLVD-CR-24-02)
Also add a reentrancy-guard to the fault handler
Mitigation for
MLLVD-CR-24-01
andMLLVD-CR-24-02
This change is