No stackframes recorded for inproc backend

[PatrickMIK]

Hi,

I'm trying to use sentry-native for crash reporting. Currently I'm working on a cross platform C++ based title, developing on macOS. To keep the setup as simple as possible, I decided to try the inproc backend first.

It seems that a lot of features work as expected. I can see activity on the Sentry dashboard. Crash reports are written to disk, and sent out to and received by Sentry. However there is one problem: the stack trace is missing in the recorded crash info:

"stacktrace": {
    "frames": [],
    "registers": {
        "x0": "0x1",
        "x1": "0x4",
        "x2": "0x1250326e8",
        "x3": "0x10401",

The register values are there, but the stack frames are not.

I tried to add the stack trace manually in an on_crash handler using sentry_event_value_add_stacktrace() but that also did not record any stack frames.

Am I missing something obvious? It seemed to me as if the stack frames should be recorded automatically, even in the inproc backend, but perhaps I didn't read all the documentation, or I mis-interpreted it. The stack frames are the most important aspect of using sentry.

I have now switched to using the breakpad backend, and that does seem to record the stack frames.

Thank for any insights,
p.

[supervacuus]

Hi @PatrickMIK,

While the inproc backend can be used on macOS, using either breakpad or crashpad on these systems is much preferable. Both backends implement mach-exception port handling, a much better supported crash-handling approach on Apple's OSes than the signal-handler we use for inproc. They also produce a minidump, providing more crash context data than currently collected via inproc (for instance, you'll get stack traces for all threads).

It seems Apple has abandoned backtrace() support in signal handlers altogether, given that it could never correctly trace signal-handlers stack frames anyway (and backtrace() not being an async-safe function to begin with). This is also why calling sentry_event_value_add_stacktrace() will have no effect when called from within on_crash because it also executes in the context of the signal-handler.

In short, if you have no specific reason to use inproc for your scenario, you should always default to breakpad or crashpad.

[PatrickMIK]

Thanks very much, that is some very useful information. We'll stick with breakpad for the time being.