Embedded crashpad handler on macOS?

[Marshall Greenblatt]

Hi All,

On Windows we currently have the option to use an embedded crashpad handler [1], which means that the crashpad handler process is launched using the same executable as the main application (with "--type=crashpad-handler"). On macOS we currently always require the bundling of a separate crashpad handler executable hard-coded at "/Contents/Frameworks/My Framework.framework/Helpers/crashpad_handler" [2].

In my Content API-based application I've implemented the embedded handler option on macOS [3] so that I can reuse the existing "/Contents/Frameworks/myapp Helper.app/Contents/MacOS/myapp Helper" executable instead of bundling a separate "crashpad_handler" executable. This seems to work fine in my local testing on macOS 10.12.1 (renderer, GPU and main process crashes are sent to my crash server), but I'm concerned that perhaps I'm missing something subtle.

Can anyone explain the technical or historical reasons for requiring a separate "crashpad_handler" executable on macOS?

Thanks,

Marshall

[1] https://cs.chromium.org/chromium/src/chrome/app/chrome_exe_main_win.cc?q=RunAsCrashpadHandler&sq=package:chromium&l=230&dr=C

[2] https://cs.chromium.org/chromium/src/components/crash/content/app/crashpad_mac.mm?q=crashpad_mac.mm+crashpad_handler&sq=package:chromium&l=45&dr=C

[3] The required changes are pretty simple: (1) make a macOS version of run_as_crashpad_handler_win.cc RunAsCrashpadHandler, and (2) modify crashpad_mac.mm PlatformCrashpadInitialization to specify the helper exe path and add the "--type=crashpad-handler" command-line flag.

[Scott Graham]

Hi Marshall,

The main reason is that Mac was done first, and there wasn't any special Chromium-related functionality required on macOS. On Windows, I was concerned about outbound firewalls, AV with poor heuristics blocking the crash handler, etc. Embedding the handler in the chrome binary was additional work in terms of communication and conventions to allow it to be launched as. Having crashpad_handler be a separate unrelated application from Chromium is somewhat desirable for stability in the sense that a bug introduced into Chromium might be avoided in the handler.

That said, it seems reasonable to support embedding the handler on other platforms. I'm not sure if Mac Chrome will want to go that way or not.

[Mark Mentovai]

Windows is actually doing the weird thing here. crashpad_handler was designed to be a distinct process from the very beginning. It’s not saddled with any of the early-startup code that the main executable is, with the heft of all of Chrome having to be mapped in, or with any static initializers that might creep in despite our best efforts to outlaw them. That’s a lot of unused and unnecessary stuff to make available to a process that’s intentionally not sharing very much with Chrome for reasons of stability. crashpad_handler potentially winds up accumulating lots of privilege, which is another reason to limit the amount of code that it might have access to.

The reason that Windows went with the embedded design was to circumvent overzealous antivirus products and binary black/whitelisters that might otherwise nix our ability to launch a distinct executable. This is a valid concern on Windows. Not so much on other systems.

There’s no reason that the --type=crashpad-handler model used by Chrome on Windows wouldn’t work elsewhere, but I still don’t know about using it for Chrome on Mac.