Skip to content

feat(native): add Crashpad retry mechanism #12980

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
merged 2 commits into from
Mar 12, 2025
Merged

feat(native): add Crashpad retry mechanism #12980

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
643c581
add crashpad retry mechanism to list of reasons
JoshuaMoelans Mar 12, 2025
02c0fba
update
JoshuaMoelans Mar 12, 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
5 changes: 3 additions & 2 deletions 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 @@ -18,6 +18,7 @@ Currently, `crashpad` is the default on all desktop platforms because it
* is the primary target for Sentry-developed extensions to the upstream implementation of backend handlers (most of which aren't a particular upside vs. the other backends, but changes to reach parity), including
* client-side stack traces (this is currently not available on `breakpad`)
* attachment handling
* retry mechanism for failed report uploads
* HTTP proxy support
* GCC and MinGW support
* `FirstChanceHandler` on Windows and extension of its synchronization to support Sentry hooks
Expand All @@ -39,7 +40,7 @@ In the above cases, if you cannot loosen the requirements of your environment, y

### 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:
Both backends are comparable in how they differ from `crashpad`. However, there are also considerable differences between the two:

* `inproc` only provides the backtrace of the crashing thread. `breakpad` records all threads in the minidump.
* similar to `crashpad`, `breakpad` uses the lowest level error handling mechanism on each platform (macOS: mach exception ports, Windows: `UnhandledExceptionFilter`, Linux: signal handlers), it does cover a smaller range of errors, though as mentioned above.
Expand All @@ -63,7 +64,7 @@ Both backends are comparable in how they differ from `crashpad`. However, there

If you dive into the details, you will find many trade-offs in the selection of backends. The above merely provides a first overview. Further, the above is only a snapshot of the current capabilities, where some trade-offs are incidental and do not follow a particular strategy or technological necessity. The primary reason for providing multiple backends is to cover as many user scenarios as possible, which requires a bit of insight if you decide to deviate from the defaults.

Sentry suggests the following sequence for your backend evaluations:
Sentry suggests the following sequence for your backend evaluations:

* `crashpad` (default)
* `breakpad`
Expand Down