Docs: Clarify inproc vs breakpad trade-offs

[bruno-garcia]

In the docs we say:

Breakpad and inproc both run "in-process", so they run in the same process as the application they capture crashes for. This means these backends can't send a crash to Sentry immediately after it happens. Instead, the crash report is written to disk and sent the next time the application is run. Since Crashpad runs in a different process it doesn't have this limitation.

But it doesn't help one understand the trade offs between inproc and breakpad.
When should I use one over the other? Any quirks depending on which platform I'm running?

How does in-proc work on each platform? For example does it use MiniDumpWriteDump on Windows?

[vaind]

possible duplicate of #908

[supervacuus]

But it doesn't help one understand the trade offs between inproc and breakpad. When should I use one over the other? Any quirks depending on which platform I'm running?

This question is indeed a duplicate of #908.

How does in-proc work on each platform? For example does it use MiniDumpWriteDump on Windows?

• inproc does not produce minidumps on any platform but only generates stack traces from OS-available unwinder infra (which led to breakage on macOS, where it doesn't work since macOS 14).
• It encodes the entire crash in the event envelope and doesn't require an attachment envelope like a breakpad or a separate endpoint.
• It uses signal handlers on macOS (rather than mach exception ports) and UEF on Windows.
• That means you only get POSIX-compatible translation of errors on macOS.
• abort() and other fast-fail crashes won't register on Windows (also true for breakpad).
• Since the inproc handler has no C++ code, it has no runtime dependency on any C++ standard library (which both breakpad and crashpad have).
• inproc is simple code (== small size) that maps much more directly to Sentry's event API (might be helpful for users who want to preprocess in their own local relay)

I have yet to see a use case where breakpad would be less convenient for users than inproc. The primary use-case for inproc is Android, and here, mainly because we use a fork of the platform-unwinder libunwindstack (both with considerable issues of their own, as documented in multiple places). Due to the low usage outside Android, the backend is the least maintained.

[bruno-garcia]

Thanks for that reply.

That information, combined with this reply is I believe very detailed and should help us make the right call.

I strongly believe that all of these details belong on the docs. They are indeed very deep and technical and I don't expect the average engineer to need to dig into them. But many Sentry users are not average engineers and will wonder "Why are my abort() not working on platform X using plugin Y?" We could point folks to those details.