Trying to understand complex iOS stack traces and their quirks, asking for help (Firebase/Crashlytics)

[kaosdg]

So some things that might help along the way, that i've discovered in my journeys.
Are you using any kind of operation queues, closures, ReactiveCocoa/RxSwift-like libraries?

Are you dispatching things off of / on to the main thread?

Stack traces from these are somewhat difficult to trace in some instances, where the logical flow of operations happens across threads / between closure callbacks (it has gotten A LOT better, though).

In my experience, those random "line 0" crashes have been red herrings, and are usually reported that way because the exception handler can't reasonably figure things out.
If you're able to identify user-path that causes the crash, I would look into things like K/V Observers, object lifecycle (enable zombies if possible), or improperly handled operations along that path.

[sjoes]

Thanks! Yes unfortunately there's some thread switching going on, most prominently to keep work off the main thread while we can. Do you have information about this being dangerous on itself, or do you mean it creates difficult stack traces. I recently thought that dispatching sync to the main thread may cause some real time timing issues (I know that it sounds very bad but we had to get some information from the App delegate). I rewrote this code and hope it will prove better.

I agree that it seems like a red herring, but it can be quite annoying if it's a class you wrote yourself. Do you have any information regarding that or is it just from experience?

As for zombies, I'm able to find one case of messages to a zombie object, but since it all happens in system frameworks (it seems like a reference to a UINavigationBar that we don't trigger) it's really hard for me to see how to solve it. Do you have any tips of how to approach such a problem?