30

I recently received this app after updating to Crashlytics 3.0 Not sure if it comes from my code or something else. The crash report is untraceable

Here is the crash report

Crashed: com.apple.main-thread EXC_BAD_ACCESS KERN_INVALID_ADDRESS at 0x000000009a0dbeb8

0   libobjc.A.dylib objc_msgSend + 16 release
1   CoreFoundation  CFRelease + 524
2   CoreFoundation  -[__NSArrayM dealloc] + 152
3   libobjc.A.dylib (anonymous namespace)::AutoreleasePoolPage::pop(void*) + 564
4   CoreFoundation  _CFAutoreleasePoolPop + 28
5   Foundation  -[NSAutoreleasePool release] + 148
6   UIKit   -[UIApplication _run] + 588
7   UIKit   UIApplicationMain + 1488
8   MyAppName   main.m line 32main
9  libdyld.dylib    start + 4
Kong Hantrakool
  • 1,865
  • 3
  • 20
  • 35
  • Is it consistently reproducible? Looks to me like you're trying to access a deallocated instance of NSArray. – brandonscript Jun 16 '15 at 18:04
  • @remus not often.But today I got 2 reports from this crash which is strange. The prior version of app has not produced one. – Kong Hantrakool Jun 16 '15 at 18:59
  • Does it happen in the debugger, or only in production app store versions? – brandonscript Jun 16 '15 at 20:14
  • @remus I am not sure but I have never experienced this bug on my testing device (development) . – Kong Hantrakool Jun 17 '15 at 03:35
  • Without being able to contact the people who are causing it to happen, I wouldn't worry about it. Especially if it's only two crashes. It starts happening a lot of the time, you'll have some more data that will help you aggregate and determine the cause. – brandonscript Jun 17 '15 at 03:37
  • Thanks for your perspective. I got another crash report today. it is objc_release crash. It is almost the same as the previous app. Not much info given. The report just claim it is from main.m – Kong Hantrakool Jun 17 '15 at 14:19
  • 1
    I am seeing an identical crash. In all of the logs I have looked through this has occurred shortly after launch. 100% of the crashes have been on iOS 8 (although most users are on 8). This is also my first release with the updated Fabric/Crashlytics frameworks. I have confirmed by grepping my entire project that I have no weak NSMutableArray properties, ivars, or local variables. Similarly, the zombie instrument didn't turn up anything. So far I have no real clue what is going on. – Alex Jun 22 '15 at 23:17
  • @Alex I think it is the problem from their side. I am already send an email to the support staff. Hope we can find the solution soon. – Kong Hantrakool Jun 23 '15 at 05:48

5 Answers5

25

It turns out to be bug of the frame work

Here is what I got from the support of Crashlytics

This should be all set if you update to 3.0.10 of the Crashlytics SDK - there was a rare race condition in 3.0.9 that we patched up with the latest version. Open up Fabric.app, update the framework and you'll be good to go :)

The support team of Crashlytics are awesome!

Kong Hantrakool
  • 1,865
  • 3
  • 20
  • 35
  • Thanks for this. Been searching for the cause of this, and was just coming around to Crashlytics! Might be useful if they reached out to devs getting this error who are on 3.0.9 to let them know! – NeilMortonNet Jul 27 '15 at 14:54
  • 2
    @MRNeilM That would have been really nice, or at least have a little warning on the Answers dashboard, "Hey if you are using Crashlytics 3.0.9 there is a crash issue present". I put in a feature request to Fabric for a RSS feed or email of their release notes when they are released. I hope they can at least do that so you would know when a new Crashlytics SDK is released. – Polar Bear Aug 06 '15 at 03:01
  • @PolarBear Agree entirely. I just got my update out, and all crashes stopped. – NeilMortonNet Aug 06 '15 at 10:27
  • looks like this issue is back again in 3.7.2 release – Pavan Kunchapu Aug 01 '16 at 06:33
  • I face this issue for 8.10.0 version of SDK – Protocol Aug 01 '22 at 14:09
7

Confirmed this was introduced in my app by Crashlytics 3.0.9 released on June 10, 2015 according to https://dev.twitter.com/fabric/overview/changelog.

Updated to Crashlytics 3.0.10 and pushed through an emergency update on Saturday. The results speak for themselves:

Went from 99.9% Crash Free on Monday, released an update on Tuesday and by Friday June 26th the Crash Free rate dropped to 98.3% which was over a 16 fold increase in users experiencing a crash. On Saturday June 27th I was able to get Apple to perform an expedited App Review and the new version with Crashlytics 3.0.10 was released into the App Store on Saturday. As you can see the Crash Free rate is now back to 99% a couple days after the release heading back towards 99.9%.

I hope this helps those of you who are pulling out your hair over a crash that was introduced by non other than your crash framework. At least they resolved it quickly and the new version appears to fully resolve the issue.

Polar Bear
  • 918
  • 2
  • 7
  • 19
6
CoreFoundation  _CFAutoreleasePoolPop + 28

Autorelease pool is being drained, probably in the end of the UI loop. That means all autoreleased objects in the pool are now released.

CoreFoundation  -[__NSArrayM dealloc] + 152

A mutable array is being released. That means all the items it is holding are being released too.

CoreFoundation  CFRelease + 524

One of the items in the array is being released.

Crash, the item is invalid, it has already been deallocated.

The thing you should inspect are items in arrays. Something is definitely overreleased. If you are using manual reference counting, you should inspect objects that you put into arrays - one of the items is deallocated but is still being kept in some array.

A code that will trigger a similar error under MRC is the following:

NSMutableArray *array = [NSMutableArray array]; //an autoreleased array
NSObject *object1 = [[NSObject alloc] init];
NSObject *object2 = [[NSObject alloc] init];

[array addObject:object1]    
[array addObject:object2]    

[object1 release];
[object2 release];

//let's overrelease
[object1 release];
//when array is released, it will send a release message to object1, too
Sulthan
  • 128,090
  • 22
  • 218
  • 270
  • thanks for this detailed answer. What could cause this in an ARC project? I'm not manually sending release or autorelease to any objects in my project. This crash appeared after a fairly minor update and I don't see anything suspect in the commits. – Alex Jun 23 '15 at 17:48
  • @Alex Hmm, hard to say. Is it reproducible? It could be a timing issue. – Sulthan Jun 23 '15 at 18:23
  • Not at all reproducible. I've never witnessed this crash myself. The last I looked it had happened 47 times out of thousands of sessions. From the logs I can see it has always occurred shortly after launch. – Alex Jun 23 '15 at 20:47
  • @Alex There are two specific things you should check - 1. some weird crashes happen because the device is jailbroken 2. people have begun to install iOS 9 beta. Try to figure out whether the problem is not connected with iOS 9. – Sulthan Jun 23 '15 at 21:07
  • Same with @Alex. I am using ARC and crash log are from iOS8. – Kong Hantrakool Jun 24 '15 at 00:29
  • it turns out to be Crashlytic/Fabric's bug see my answer – Kong Hantrakool Jun 24 '15 at 01:25
2

it seems to your NSArray released & you want to access it so this crash happened. you can define your NSArray as Strong in your model or VC

@property(nonatomic, strong) NSArray *myArray

if you cant guess which NSArraY has been released , I recommend you debug your app with NSZombie Object in instrument to find exact NSArray

Mo Farhand
  • 1,144
  • 8
  • 21
2

It happens with me many times. just add Strong reference for every NSArray in your code. and then you will never see the error like you have seen.

Better use the below code:

@property(strong) NSArray *myArray.
Mohammad Faisal
  • 5,783
  • 15
  • 70
  • 117
Code Hunterr
  • 175
  • 9