I've heard/lived enough horror stories about AV, outbound-blocking
firewalls, etc. on Windows, that I think the best approach is to have
chrome.exe embed the majority of crashpad_handler and jump to it as
early as possible when running in that mode.
So, move most of crashpad_handler into a static_library with just main()
in the executable target.
R=mark@chromium.org
BUG=chromium:546288, crashpad:27
Review URL: https://codereview.chromium.org/1416873016 .
This consolidates all of the twisted casts and comments that discuss how
HANDLEs are really only 32 bits wide even in 64-bit processes on 64-bit
operating systems into a single location.
R=scottmg@chromium.org
Review URL: https://codereview.chromium.org/1422503015 .
Allowing the client to create its own pipe name string caused a race
between client and server. Instead, in this mode, the server now creates
the pipe name along with a pipe, and returns it to its client via a
--handshake-handle. This guarantees that by the time the client gets the
pipe name, the server has already created it.
Ephemeral mode is now implied by --handshake-handle. The --persistent
option is gone. --persistent mode is enabled when using --pipe-name.
BUG=crashpad:69
R=scottmg@chromium.org
Review URL: https://codereview.chromium.org/1432563003 .
By invoking crashpad_handler with --mach-service instead of
--handshake-fd, the handler will run as a well-behaved launchd job. The
launchd job may be as a launch agent or launch daemon, or be submitted
to launchd by on_demand_service_tool.
BUG=crashpad:25
R=rsesek@chromium.org
Review URL: https://codereview.chromium.org/1414533006 .
Previously, crashpad_handler made its own receive right, and transferred
a corresponding send right to its client. There are two advantages to
making the receive right in the client:
- It is possible to monitor the receive right for a port-destroyed
notificaiton in the client, allowing the handler to be restarted if
it dies.
- For the future run-from-launchd mode (bug crashpad:25), the handler
will obtain its receive right from the bootstrap server instead of
making its own. Having the handler get its receive right from
different sources allows more code to be shared than if it were to
sometimes get a receive right and sometimes make a receive right and
transfer a send right.
This includes a restructuring in crashpad_client_mac.cc that will make
it easier to give it an option to restart crashpad_handler if it dies.
The handler starting logic should all behave the same as before.
BUG=crashpad:68
R=rsesek@chromium.org
Review URL: https://codereview.chromium.org/1409073013 .
This allows better code sharing in crashpad_handler’s main(). It doesn’t
look like much of an improvement now, but a separate change will cause
the Mac ExceptionHandlerServer() to be constructed with an argument. It
will be beneficial for Mac and Windows to be able to share the Run()
call.
R=scottmg@chromium.org
Review URL: https://codereview.chromium.org/1402333004 .
The intended use is to flip the client-server relationship in
CrashpadClient so that the initial client (parent process) furnishes the
handler process with a receive right. The parent can optionally receive
a port-destroyed notification allowing it to restart the handler if it
exits prematurely.
R=rsesek@chromium.org
Review URL: https://codereview.chromium.org/1408473002 .
I’ve accidentally created Crashpad databases when running
crashpad_database_util by mistyping the argument to --database. Typical
users of crashpad_database_util probably don’t want the database to be
created.
This adds a new --create option to crashpad_database_util that is
required to get it to create a database. If not present, a database will
not be created if it does not already exist.
TEST=crashpad_client_test CrashReportDatabaseTest.*
R=rsesek@chromium.org, scottmg@chromium.org
Review URL: https://codereview.chromium.org/1395653002 .
This is a weird option that causes crashpad_handler to discard the crash
handler it inherited and replace it with the system default. Its use is
not recommended.
BUG=chromium:538373
R=rsesek@chromium.org
Review URL: https://codereview.chromium.org/1391463002 .
