feat(native): add backend trade-offs to Advanced Usage #11721
Conversation
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎
1 Skipped Deployment
|
Bundle ReportChanges will increase total bundle size by 193.14kB (1.28%) ⬆️. This is within the configured threshold ✅ Detailed changes
|
docs/platforms/native/advanced-usage/backend-tradeoffs/index.mdx
Outdated
Show resolved
Hide resolved
docs/platforms/native/advanced-usage/backend-tradeoffs/index.mdx
Outdated
Show resolved
Hide resolved
docs/platforms/native/advanced-usage/backend-tradeoffs/index.mdx
Outdated
Show resolved
Hide resolved
docs/platforms/native/advanced-usage/backend-tradeoffs/index.mdx
Outdated
Show resolved
Hide resolved
docs/platforms/native/advanced-usage/backend-tradeoffs/index.mdx
Outdated
Show resolved
Hide resolved
docs/platforms/native/advanced-usage/backend-tradeoffs/index.mdx
Outdated
Show resolved
Hide resolved
docs/platforms/native/advanced-usage/backend-tradeoffs/index.mdx
Outdated
Show resolved
Hide resolved
|
|
||
| * `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. | ||
| * `inproc`, on the other hand, uses signal handling on Linux and macOS (meaning you only get a `POSIX` compatibility layer over mach exception ports) and `UnhandledExceptionFilter` on Windows (solely errors registered by SEH) |
There was a problem hiding this comment.
(solely errors registered by SEH)
This could use further clarification on differences between inproc and breakpad
There was a problem hiding this comment.
I wanted to say here that they use the same mechanism, and UnhandledExceptionFilter and SEH have equivalent meanings in this case. I can see how this easily reads as a distinction between breakpad and inproc. Should I remove it?
docs/platforms/native/advanced-usage/backend-tradeoffs/index.mdx
Outdated
Show resolved
Hide resolved
docs/platforms/native/advanced-usage/backend-tradeoffs/index.mdx
Outdated
Show resolved
Hide resolved
Co-authored-by: Karl Heinz Struggl <[email protected]>
Co-authored-by: Karl Heinz Struggl <[email protected]>
Co-authored-by: Karl Heinz Struggl <[email protected]>
Co-authored-by: Karl Heinz Struggl <[email protected]>
Co-authored-by: Ivan Dlugos <[email protected]>
Co-authored-by: Ivan Dlugos <[email protected]>
Co-authored-by: Karl Heinz Struggl <[email protected]>
| Currently, `crashpad` is the default on all desktop platforms because it | ||
|
|
||
| * has an external `handler` process that allows for external snapshots and sending crash reports immediately (instead of on the next successful start of your application) | ||
| * is the primary target for extension compared to upstream, including |
There was a problem hiding this comment.
It's late so maybe that's why but I don't understand this sentence
specifically "target for extension compared to upstream", what's upstream in this case? and what extension are you referring to?
|
|
||
| * has an external `handler` process that allows for external snapshots and sending crash reports immediately (instead of on the next successful start of your application) | ||
| * is the primary target for extension compared to upstream, including | ||
| * client-side stack traces |
There was a problem hiding this comment.
sorry if this is a dumb question, but what does this mean? Is that vs "server-side stack traces"?
Don't we create a minidump with crashpad and hence stack walk on the server?
| * has an external `handler` process that allows for external snapshots and sending crash reports immediately (instead of on the next successful start of your application) | ||
| * is the primary target for extension compared to upstream, including | ||
| * client-side stack traces | ||
| * attachment handling |
There was a problem hiding this comment.
Does this indicate we don't attachments using other backends?
I believe crashpad only allows specifying attachments during init, is that right? That can be seeing as a limitation. And technically we should be able to support attachments on the other backends (not by the backend themselves, but by the SDK. Hold on to the paths, on restart if the files are there, send them. No?)
|
|
||
| Sentry decided on `crashpad` as the default on all platforms because there are a lot of upsides. However, there are use cases where `crashpad` cannot be used or makes distribution or deployment much harder. We provide other backends for situations when | ||
|
|
||
| * you cannot package or deploy an additional executable (the `crashpad_handler`) |
There was a problem hiding this comment.
is it useful to add 'or spawn'? Given environments where there's a sandbox and we can't create child processes? (Xbox and UWP I believe?)
| * you cannot package or deploy an additional executable (the `crashpad_handler`) | |
| * you cannot package, deploy or spawn an additional executable (the `crashpad_handler`) |
I see this might be covered in the next two lines though
|
|
||
| ### So when do I choose `inproc`? | ||
|
|
||
| `inproc` is currently the backend of choice for `Android` because it allows us to couple it with our own fork of a powerful platform unwinder `libunwindstack` (rather than relying on a user-space interface). This allows us to support very old Android versions. |
There was a problem hiding this comment.
In
| `inproc` is currently the backend of choice for `Android` because it allows us to couple it with our own fork of a powerful platform unwinder `libunwindstack` (rather than relying on a user-space interface). This allows us to support very old Android versions. | |
| `inproc` is currently the backend of choice for `Android` because it allows us to couple it with our own fork of a powerful platform unwinder `libunwindstack` (rather than relying on a user-space interface). This allows us to support very old Android versions. In addition, stack walking on device on Android is preferred since we don't have all system symbols available for server-side symbolication. A [best-effort symbol collection exists](https://github.com/getsentry/symbol-collector), but that'll never be as reliable as stackwalking on device. |
DESCRIBE YOUR PR
I try to cover some of the surface area of the tradeoffs involved when choosing a backend in the Native SDK. This was requested by downstream SDK maintainers (ref: issues below).
Fixes: getsentry/sentry-native#908
Fixes: getsentry/sentry-native#1070
IS YOUR CHANGE URGENT?
Help us prioritize incoming PRs by letting us know when the change needs to go live.
SLA
Thanks in advance for your help!
PRE-MERGE CHECKLIST
Make sure you've checked the following before merging your changes:
LEGAL BOILERPLATE
Look, I get it. The entity doing business as "Sentry" was incorporated in the State of Delaware in 2015 as Functional Software, Inc. and is gonna need some rights from me in order to utilize my contributions in this here PR. So here's the deal: I retain all rights, title and interest in and to my contributions, and by keeping this boilerplate intact I confirm that Sentry can use, modify, copy, and redistribute my contributions, under Sentry's choice of terms.
EXTRA RESOURCES