objc msgSend [NSArrayM dealloc] отчет о сбоях иногда из Crashlytics

Я недавно получил это приложение после обновления приложений 3.0 Не уверен, идет ли это из моего кода или что-то еще. Отчет о крушении не отслеживается

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
27
crashlytics fabric-twitter ios objective-c

5 ответов

оказывается, ошибка работы фрейма

вот что я получил от поддержки приложений

Это должно быть все настроено, если вы обновите до 3.0.10 Crashlytics SDK - в 3.0.9 было редкое состояние гонки, которое мы исправили с последней версией. Откройте ткань.app, обновить структуру, и вы будете хорошо идти:)

команда поддержки Crashlytics потрясающая!

24

подтверждено, что это было введено в мое приложение Crashlytics 3.0.9 выпущено 10 июня 2015 года в соответствии с https://dev.twitter.com/fabric/overview/changelog.

обновлено до Crashlytics 3.0.10 и прошло экстренное обновление в субботу. Результаты говорят сами за себя:

пошел от 99.9% Crash Free в понедельник, выпустил обновление во вторник и к пятнице 26 июня безаварийная ставка упала до 98,3% , который был более 16 кратное увеличение пользователей, испытывающих сбой. В субботу 27 июня я смог заставить Apple выполнить ускоренный обзор приложений, и новая версия с Crashlytics 3.0.10 была выпущена в App Store в субботу. Как вы можете видеть, безаварийная скорость теперь возвращается к 99% через пару дней после выпуска, возвращаясь к 99.9%.

Я надеюсь, что это поможет тем из вас, кто вытаскивает волосы из-за аварии, которая была введена non, кроме вашей структуры аварии. Хотя бы они решено быстро, и новая версия, похоже, полностью решит проблему.

7
CoreFoundation  _CFAutoreleasePoolPop + 28

Autorelease пул сливают, вероятно, в конце цикла пользовательского интерфейса. Это означает, что все объекты autoreleased в бассейн теперь освобождены.

CoreFoundation  -[__NSArrayM dealloc] + 152

выпускается изменяемый массив. Это означает, что все предметы, которые он держит, также освобождаются.

CoreFoundation  CFRelease + 524

освобождается один из элементов массива.

сбой, элемент недействителен,он уже был освобожден.

вещь вы должны проверить детали внутри матрицы. Что-то определенно overreleased. Если вы используете ручной подсчет ссылок, вы должны проверить объекты, которые вы помещаете в массивы - один из элементов освобожден, но все еще хранится в некотором массиве.

код, который вызовет аналогичную ошибку в MRC, следующий:

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
6

Кажется, что ваш NSArray выпущен , и вы хотите получить к нему доступ, чтобы произошел этот сбой. вы можете определить свой NSArray как сильный в вашей модели или VC

@property(nonatomic, strong) NSArray *myArray

Если вы не можете угадать, какой NSArraY был выпущен , я рекомендую вам отладить приложение с помощью объекта NSZombie в инструменте, чтобы найти точный NSArray

2

Это случилось со мной много раз. просто добавьте сильную ссылку для каждого NSArray в коде. и тогда вы никогда не увидите ошибки, как вы видели.

лучше использовать приведенный ниже код:

@property(strong) NSArray *myArray.
2