You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We've recently updated from breakpad to crashpad. Our executable is signed and it keeps things simpler and reduces duplication on disk to minimize the number of executables in our application. So instead of having a separate crashpad_handler.exe, we were able to link the libraries that crashpad_handler uses into our main executable and call crashpad::HandlerMain when we detect we're being invoked to run as the crashpad_handler.
To get this working, we use this sentry-native repo as a submodule.
#include<handler/handler_main.h>
...
if (running_in_crashpad_mode) {
returncrashpad::HandlerMain(argc, argv, NULL);
}
The last piece is how we detect we're running in "crashpad mode". We could have looked at the command-line parameters and likely inferred we're supposed to run in crashpad_handler mode, but to be more certain we still work across version updates, we employed a bit of a hack. We add a dummy "attachment" which gets passed on the command-line as --attachment=CrashpadMode. We then filter this extra dummy parameter when we forward argv to crashpad::HandlerMain.
We'd like to request sentry to consider this way of integrating crashpad as a new officially supported workflow. This should enable applications to upgrade to crashapd from the inproc/breakpad backends that weren't able to becuase of the extra executable requirement. Also note that this works today, but here's some things that would make it a bit easier:
1. CommandLine Identification
An officially supported mechanism for an application exe to know it should be running as the crashpad handler. Possibly something like this:
Hey @marler8997, thanks for writing in and your suggestions! I'm putting this on our backlog as we don't have the bandwidth to tackle this atm. Happy to bump prio if we see demand for this.
We've recently updated from breakpad to crashpad. Our executable is signed and it keeps things simpler and reduces duplication on disk to minimize the number of executables in our application. So instead of having a separate
crashpad_handler.exe
, we were able to link the libraries that crashpad_handler uses into our main executable and callcrashpad::HandlerMain
when we detect we're being invoked to run as the crashpad_handler.To get this working, we use this sentry-native repo as a submodule.
We use the corresponding CMake files, i.e.
Then we link these libraries into our executable:
Then inside our application we add:
The last piece is how we detect we're running in "crashpad mode". We could have looked at the command-line parameters and likely inferred we're supposed to run in crashpad_handler mode, but to be more certain we still work across version updates, we employed a bit of a hack. We add a dummy "attachment" which gets passed on the command-line as
--attachment=CrashpadMode
. We then filter this extra dummy parameter when we forward argv tocrashpad::HandlerMain
.We'd like to request sentry to consider this way of integrating crashpad as a new officially supported workflow. This should enable applications to upgrade to crashapd from the inproc/breakpad backends that weren't able to becuase of the extra executable requirement. Also note that this works today, but here's some things that would make it a bit easier:
1. CommandLine Identification
An officially supported mechanism for an application exe to know it should be running as the crashpad handler. Possibly something like this:
2. Only require linking against a single library to link in crashpad_handler
i.e.
I think this could be done with a bit of extra cmake.
3. Avoid conflicts with application headers by namespacing
The text was updated successfully, but these errors were encountered: