Implementing a crash reporter - panic and abort signal

help
1

I’m trying to implement a crash reporter for an app. I installed a panic hook (std::panic::set_hook) and also signal handlers (using the signal-hook crate). To avoid a double report, I uninstall the abort signal handler in the panic hook. This seemed to work, but now on Android it doesn’t. On Android, the handler for the SIGABRT still runs after the panic, and makes a second report file. This is odd to me because the signal-hook crate’s unregister function is not changing the low level C library signal handler, but rather a map of functions in Rust. So I don’t see why it’s behaving differently.

Any ideas?

(This scheme is a bit messed up with multithreading, since I could be getting panics that don’t crash the app. … Haven’t dealt with that yet.)

2

Maybe you could let both handlers run, and have a static atomic variable (Once in std) that is set by either handler to disable reporting from the other one?

3

Yeah, I’ll probably do that. I don’t know of a way to tell in the abort handler that it’s connected to a previous panic handler. Checking time elapsed is a bit hacky.

1 Like
4

Not really an answer to your question and I've not tried this in Rust but I'm pretty familiar with Android's default signal handlers and how you can chain another handler - I'm surprised that this works at all?

signal-hook says it chains to the previously-installed signal handler before running the action the caller asked for, and in an Android app process there's always a previous signal handler for SIGABRT (and other signals that are crash-y) that invokes debuggerd/crashdumpd to generate the platform's crash report, and that handler resets the signal back to SIG_DFL and then retriggers the signal afterwards, which seems like it would result in your handler never running at all...

If you want to handle signals yourself Android is expecting you to do that logic before chaining to the previously-installed handler, which is what Breakpad/Crashpad/various other crash handling libs that support Android do.

(there's also libsigchain interposing itself into all the libc functions that set up signal handlers to make sure that ART's signal handlers always actually run first and any other handler only sees signals after ART decided it doesn't care, but ART doesn't handle SIGABRT so shouldn't be involved there?)