crashpad_handler’s current persistent mode of operation, involving the
child_port_handshake with its initial client, was designed to support
drag-installed applications like Chrome that don’t have a fixed installation
location or uninstall flow.
Applications (or services) with a fixed installation location and
install/uninstall flow can use Crashpad in a non-persistent mode, where
crashpad_handler is invoked on demand by launchd from a LaunchAgent or
LaunchDaemon. Keystone may be a consumer interested in this mode.
crashpad_handler in this mode should not do a child port handshake, but should
instead use bootstrap_check_in() to check in with a known Mach service name.
This name should be unique per application using Crashpad. When running in this
way, crashpad_handler should process exception messages and exit after a
configurable timeout. The Mach service name and timeout can be passed on the
command line. Applications can use a launchd plist that specifies this service
name and perhaps requests that the database be watched.
CrashpadClient should get a new method that can be called to set the handler up
based on bootstrap_look_up(). This method would be called by Crashpad’s
initial client when it sets up Crashpad handling instead of StartHandler(). It
would call this new method before calling UseHandler().
Original issue reported on code.google.com by mark@chromium.org on 26 Mar 2015 at 9:46
Original issue reported on code.google.com by
mark@chromium.orgon 26 Mar 2015 at 9:46