-
Notifications
You must be signed in to change notification settings - Fork 19
fix(crashtracking): guard sigchld and sigpipe during crashtracker signal handler execution #1771
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
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -5,6 +5,7 @@ | |
|
|
||
| use super::collector_manager::Collector; | ||
| use super::receiver_manager::Receiver; | ||
| use super::saguard::SaGuard; | ||
| use super::signal_handler_manager::chain_signal_handler; | ||
| use crate::crash_info::Metadata; | ||
| use crate::shared::configuration::CrashtrackerConfiguration; | ||
|
|
@@ -263,6 +264,15 @@ fn handle_posix_signal_impl( | |
| return Ok(()); | ||
| } | ||
|
|
||
| // Block SIGCHLD and SIGPIPE during crash handling. Our collector spawns child processes | ||
| // and writes to pipes, both of which can generate these signals. Rather than risk | ||
| // re-entering a signal handler or aborting due to SIGPIPE, suppress them for the | ||
| // duration and restore when the guard drops | ||
| let _sa_guard = SaGuard::new(&[ | ||
| nix::sys::signal::Signal::SIGCHLD, | ||
| nix::sys::signal::Signal::SIGPIPE, | ||
|
Comment on lines
+272
to
+273
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. are we sure those are the only signals to suppress?
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I believe so, because those are the only two signals the crash handler itself can cause: SIGCHLD: The SaGuard's purpose isn't to block all signals but to prevent the crash handler from re-entering the application's signal handlers due to side effects of its own work WDYT?
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. For papertrail and context: Suppressing SIGPIPE AND SIGCHLD was the previous behavior before this guard was accidentally removed. I will investigate chaining SIGCHLD |
||
| ]); | ||
|
|
||
| // Take config and metadata out of global storage. | ||
| // We borrow via raw pointer and intentionally leak (do not reconstruct the Box) to avoid | ||
| // calling `drop`, and therefore `free`, inside a signal handler, which is not | ||
|
|
||
Uh oh!
There was an error while loading. Please reload this page.
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.
The reason I do this
SIGCHLD -> SIG_IGN -> kernel auto-reaps collector child ->
waitpidreturns ECHILD ->reap_child_non_blockingreturns unexpected result ->debug_assert_eq!atprocess_handle.rs:33fails ->format!allocates to build the panic message -> preload detector catches malloc.We should be running this test in release mode anyways