I am using Crashlytics to track and fix crashes in my live app. However, I am not very knowledgeable on how to understand what the thread is telling me.
Usually on XCode, you get specific information regarding the error (such as, "unexpectedly found nil", etc.). Is there such information in a Crashlytics Dashboard? If not, how can I understand better what is causing the crash in the app?
Here is a picture of an example crash.
Thanks!
You error is inside cellForRowAtIndexPath. If I'm not mistaken, The blue labels are methods inside your classes.
And they work like a bread crumbs trail for all the processes that happened until the crash. 0 is the first interaction where N is the last method triggered before your app crashed.
But you must agreed with me that your problem probably isn't inside UIKit or Foundation methods, right?
Is that helpful?
If not, feel free to contact their support, they are really responsive!
Here is they're email: support#fabric.io
Related
Users are getting this crash in testing. My first guess was that it's memory-related but I don't have much more to go off of than that. Looking deeper into the code, I thought this might have been a Main Thread issue but it looks like listeners are removed on a background thread, so I'm skeptical that that's the reason.
I thought that removing any active listeners when the app backgrounds and re-adding them when the app foregrounds might negate this crash but it doesn't seem to have helped.
Any advice on how to fix this crash? Thanks!
Edit: I left the simulator open for long enough and I got this, which is probably the same crash.
Edit 2: Profiling with the Leaks Instrument didn't turn up anything related to Firestore. It only had 7 small leaks related to Foundation and UIKit after the app closed
Looks like this was introduced in 0.15.0 – https://github.com/firebase/firebase-ios-sdk/issues/2138
I'm struggling to debug a crash that's being reported repeatedly in Crashlytics. Here is a screenshot of the report. Seems that it's caused by Google Analytics (reporting the crash on the GAIThread) but not sure what steps I need to take to address this? I've been unable to reproduce the issue and not even sure what is triggering this.
Has anyone else had experience with EXC_BAD_ACCESS KERN_PROTECTION_FAILURE caused by GA or similar?
Former Crashlytics SDK maintainer here. Information might be stale - best to check in with them for latest information.
The crashtlyics SDK protects itself from infinite recursion (which can produce hundreds of thousands of frames) by truncating repeated frames after a certain threshold. To me, it looks like that's exactly what happened here. The crash occurred in a random function that just happened to be running when the stack overflowed.
What I would do is, first, make sure you have the latest version of this Google SDK. I then might check in with them to see if they know of any reason why that function might recurse. Or, perhaps some documentation covers those conditions and/or options that might affect it's behavior.
I am facing this weird random crash where I get EXC_BAD_ACCESS on an object that exists. I am totally stumped on why this is happening. The code in the image executes without any issues 99.99% of the time. I saw this crash second time and that when I thought I should figure out what might be going wrong. I am executing this code on the main thread and the crash line has two core data objects. This shouldn't be a concurrency issue because it's only used in this class. Scary part is that object is there, values are there, still, I am getting EXC_BAD_ACCESS. Any ideas why this might be happening?
Let me know if you guys need more info. And thanks in advance for your help. :)
EDIT 1
Definition of Employee and EmployeeForTask (the class declarations are empty and has no variable defined in it, it just inherits from NSManagedObject)
You should enable NSZombies. Zombies helps to detect these kind of crashes by logging problem in console. you can enable zombies by :Click on Product⇒Edit Scheme to open the sheet and set the Enable Zombie Objects check box
When building app on real device then disable Zombies. Otherwise app will not run on device.
From time to time, Xcode Crashes comes up with a crash that i cannot understand. I pasted the xccrashpoint to gist
It states, that Thread 12 crashed somewhere in CoreGraphics called by CorePDF, called by QuartzCore drawing some layers. This seems like OS-called code, maybe via thread 1 which is doing _saveSnapshotWithName. So i assume, that this happens when closing the app.
Does anyone have at least a rough idea what is going on here? Maybe someone saw something similar before and can give a hint about what is crashing…
There is nothing special in the app that would cause dramatically wrong behaviour when leaving the app (-> when a screenshot ist taken).
Exec bad errors occur when an attempt is made to access a object or memory location which is not yet initialized.
There might be a problem with an object which you are not defining global.
Check if there is any object you defining and initializing in a method and trying to access out of the scope.
For more details related to errors and crashes, please go through below link.
http://www.raywenderlich.com/10209/my-app-crashed-now-what-part-1
I'm trying to debug an EXC_BAD_ACCESS crash using NSZombie. My app creates lots of large objects though and with NSZombie enabled they aren't getting released causing the app to crash in seconds. This means I can't even cause the EXC_BAD_ACCESS crash before the app crashes due to low memory.
Is there an alternative? Can I enable NSZombie on specific file instead of the entire project? How else could I debug this crash (I know it's caused by UIGestureRecognizer but I use them a lot so it doesn't narrow down the issue significantly).
Thanks.
Edit:
Thanks for the advice. I think I may have solved the issue and will report back after more testing.
Edit 2: Sovled the issue myself but selected the answer which seems like it would be a good solution to any similar issues in the future.
All I can think of is implementing it manually; create a proxy container that holds an object of type id and nominates that as -forwardingTargetForSelector: as well as getting it to respond to -isKindOfClass:, etc.
Disable ARC for the proxy and have it retain itself during init and check its own retainCount when nominating a forwarding target.
If the count is 1 then raise an exception or log a warning or whatever.
Have suspect classes wrap themselves in and return a proxy as the last line of their unit.
For possible bonus points, store [NSThread callStackSymbols] somewhere (probably on disk) during the proxy's unit so you can at least find out where the incorrectly managed object was created.
NSZombies was/is for apps that use their own memory management. If your app uses ARC then this won't help.
Create a new Breakpoint: All Exceptions
That should usually show you where you trigger the bad access.