Child process inheritance of crash handling on macOS

[Jonathan Jones]

Hello,

We have observed that a parent process configured for Crashpad crash handling passes this information on to the child process on macOS.  So, we are getting periodic crash dumps for processes unrelated to what we are interested in monitoring.

This document mentions that "Crashpad provides a facility for a process to disassociate (unregister) with an existing crash handler", but I cannot find the specifics for how to accomplish this.  Can someone point me to the code necessary to accomplish this?

Best wishes,

Jonathan Jones

MathWorks

[Mark Mentovai]

Jonathan Jones wrote:

That document is referring to crashpad::CrashpadClient::UseSystemDefaultHandler. But your quote interrupts the sentence in the middle. The rest of the sentence explains one intended use case. What you’re asking about is really out of scope for that function.

If you call that function in your own process, you disconnect Crashpad from handling your own process’ crashes. For cases like yours, it’s intended to be called from the child, but since it doesn’t sound like you control the child process that you do want to disconnect from Crashpad, you’d need to introduce an additional step. You could spawn an intermediate child process that you do control call and have it this function, and then have it process execve (or similar) the executable you don’t control. Another option would be to start your child process with posix_spawn and take advantage of posix_spawnattr_setexceptionports_np. Crashpad doesn’t provide direct support for this, but you can get a send right to the system-default handler (as crashpad::CrashpadClient::UseSystemDefaultHandler does) by calling crashpad::SystemCrashReporterHandler. The implementation of SetCrashExceptionPorts may be helpful in working out what to pass via posix_spawnattr_setexceptionports_np’s mask, behavior, and flavor parameters.

Heading off a bad option: it’s possible to save a send right to the Crashpad handler by calling crashpad::CrashpadClient::GetHandlerMachPort, disconnecting from Crashpad by calling crashpad::CrashpadClient::UseSystemDefaultHandler, spawning the child to not be monitored, and then reestablishing Crashpad as the crash handler with crashpad::CrashpadClient::SetHandlerMachPort, providing the right previously saved. That leaves you without crash coverage during that window, which is undesirable in any case, but particularly so in a threaded application—and it’s hard to imagine anything of substance that’s not threaded.

Best wishes,

Jonathan Jones

MathWorks

--
You received this message because you are subscribed to the Google Groups "Crashpad-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to crashpad-dev...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/crashpad-dev/053e404b-71c4-4bf0-bf35-8364434f1969n%40chromium.org.

[Jonathan Jones]

Okay, changing how we spawn every process might be a problem.  Is there at least a way to tell the handler process to never upload minidumps from any process that wasn't explicitly configured to use Crashpad.

[Mark Mentovai]

Jonathan Jones wrote:

Okay, changing how we spawn every process might be a problem.  Is there at least a way to tell the handler process to never upload minidumps from any process that wasn't explicitly configured to use Crashpad.

No, you’d be on your own to implement something like that and include it in your own build of crashpad_handler.

You might be able to achieve this by tweaking crashpad::CrashReportExceptionHandler::CatchMachException. The default for client_options.crashpad_handler_behavior will be crashpad::TriState::kUnset. You could change that line to require that client_options.crashpad_handler_behavior == TriState::kEnabled. Then, in the processes that you want to have crashpad_handler monitor, you’d need to call crashpad::CrashpadInfo::set_crashpad_handler_behavior, passing crashpad::TriState::kEnabled.

This is an inferior solution to what has been previously discussed, because your crashpad_handler will remain the exception handler for processes you don’t care about, will assume responsibility for forwarding exceptions to the system-default handler, and won’t be able to exit, even after your application exits, until any child process your application has spawned has also exited. This long-running crashpad_handler that outlives your applicaton’s lifetime can cause unexpected behaviors, including not being able to move, remove, or replace your application on disk. I can’t endorse this approach.