Crashes on app startup don't have stacktrace/version/anything

[edenman]

Expected behavior

Crashes have a minimum set of information about what went wrong

Observed behavior

Certain crashes soon after app startup have no information: https://app.bugsnag.com/recharge-labs/ios/errors/5a53e4e1931c7b0018ff868a (missing stacktrace, device information, app information, user information)

Steps to reproduce

Crash on startup

Version

5.14.0

I contacted support about this and got this response:

Errors like these show up when Bugsnag detects a crash that does not have an associated stacktrace. It's likely that the crash occurred so immediately that a stacktrace could not be generated before the application exited.

Unfortunately, there's no reliable way to gather more information when an iOS application crashes on startup so Bugsnag just sends an event to at least highlight the occurrence.

So

1. I don't understand the technical reason why the stacktrace and app/device info are unable to be captured. Can somebody elaborate?
2. Can you point me to the code that causes the "just sends an event to at least highlight the occurence" procedure to happen?

• It was super-frustrating to know that the app was crashing, but not have literally any useful information to figure out why.
• Also frustrating: I have since released an app version that fixes the issue, but marking the Bugsnag issue as "Fixed" doesn't have any effect because there's no app version attached, so Bugsnag's web interface doesn't know that new occurrences are from the old app. I could "Ignore" the issue, but then I'm at risk of a subsequent app version having this sort of crash, and never know that it's happening.

[fractalwrench]

There are a few scenarios where stacktraces can't be captured:

Failed allocation errors

std::bad_alloc can be thrown when the system is out of memory. Bugsnag uses the KSCrash library internally, which cannot capture C++ exceptions from linked libraries. This is because these linked libraries use the system __cxa_throw function rather than a custom one installed by KSCrash, meaning no stacktrace is available.

Missing unwind data

This technical note details another scenario where stack unwind data is not available.

64-bit iOS uses a "zero-cost" exception implementation. In a "zero-cost" system, every function has additional data that describes how to unwind the stack if an exception is thrown across the function. If an exception is thrown across a stack frame that has no unwind data then exception handling cannot proceed and the process halts. There might be an exception handler farther up the stack, but if there is no unwind data for a frame then there is no way to get there from the stack frame where the exception was thrown. Specifying the -no_compact_unwind flag means you get no unwind tables for that code, so you can not throw exceptions across those functions.

Additionally, if you are including plain C code in your application or a library, you may need to specify the -funwind-tables flag to include unwind tables for all functions in that code.

As an additional note, we have recently updated our backend so that errors with an empty stacktrace are displayed. Previously they were discarded.

I've passed on details of marking an issue as "Fixed" to our web team, who will investigate further.

[edenman]

Thanks for the information! In this case, the crash was a seemingly-straightforward Swift "you tried to access this implicitly unwrapped optional before it had been set" issue.

I don't fully understand the unwind data thing, but I acknowledge that there might just be something unavoidable about the stacktrace being missing. Can you elaborate on why the app/device information isn't uploaded?

[fractalwrench]

I've discussed this with @kattrali and there's another scenario, where KSCrash itself crashes. If this happens a minimal report will be recorded, which won't contain the app/device information.

We can amend this minimal report to include basic information such as app version.

[edenman]

That would be great, thanks!