问题
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
回答1:
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!
回答2:
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.
回答3:
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
回答4:
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
回答5:
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.
来源：https://stackoverflow.com/questions/30874714/objc-msgsend-nsarraym-dealloc-crash-report-sometimes-from-crashlytics