Skip to content

feat(native): add crashpad-wait-for-upload option #13117

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
JoshuaMoelans merged 3 commits into from
Mar 25, 2025
Merged

feat(native): add crashpad-wait-for-upload option #13117

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
2e1356c
add crashpad-wait-for-upload option
JoshuaMoelans Mar 25, 2025
99b53ba
edit backend tradeoffs for crashpad
JoshuaMoelans Mar 25, 2025
12eab91
apply suggestion
JoshuaMoelans Mar 25, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
3 changes: 2 additions & 1 deletion docs/platforms/native/advanced-usage/backend-tradeoffs/index.mdx
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -32,12 +32,13 @@ Sentry decided on `crashpad` as the default on all platforms because there are a
* you cannot package or deploy an additional executable (the `crashpad_handler`)
* you cannot allow a secondary process to connect via `ptrace` to your application (AWS Lambda, Flatpak-, Snap-Sandboxes)
* IPC between your process and the `crashpad_handler` is inhibited by security settings or not available in your deployment target
* your deployment scenario cannot wait for the `crashpad_handler` to finish its work before a shutdown-after-crash (systemd, Docker)
* you want to distribute your application via the macOS App Store
* you want to define crash hooks on macOS because there, error handling happens entirely in the `crashpad_handler`, whereas on Linux and Windows, at least the initial handling happens in your process, after which `crashpad_handler` takes over and snapshots the process to send a crash report

In the above cases, if you cannot loosen the requirements of your environment, you have to choose an in-process backend (meaning either `breakpad` or `inproc`).

When your deployment scenario should wait for the `crashpad_handler` to finish its work before a shutdown-after-crash (systemd, Docker), you can enable the option [`crashpad_wait_for_upload`](/platforms/native/configuration/options/#crashpad-wait-for-upload) to delay application shutdown until the upload of the crash report is completed.

### How do I decide between `breakpad` or `inproc`?

Both backends are comparable in how they differ from `crashpad`. However, there are also considerable differences between the two:
Expand Down
6 changes: 6 additions & 0 deletions docs/platforms/native/common/configuration/options.mdx
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -60,6 +60,12 @@ This variable controls the total amount of breadcrumbs that should be captured.

</ConfigKey>

<ConfigKey name="crashpad-wait-for-upload">

Whether Crashpad should delay application shutdown until the upload of the crash report in the `crashpad_handler` is complete. This is useful for deployment in `Docker` or `systemd`, where the life cycle of additional processes is bound by the application life cycle.

</ConfigKey>

## Hooks

These options can be used to hook the SDK in various ways to customize the reporting of events.
Expand Down