Подтвердить что ты не робот

Objc_msgSend [__NSArrayM dealloc] сообщение об ошибке иногда из Crashlytics

Недавно я получил это приложение после обновления до 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
4b9b3361

Ответ 1

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

Вот что я получил от поддержки Crashlytics

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

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

Ответ 2

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

Обновлен до Crashlytics 3.0.10 и прошел через аварийное обновление в субботу. Результаты говорят сами за себя: HtR3ZsU.png

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

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

Ответ 3

CoreFoundation  _CFAutoreleasePoolPop + 28

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

CoreFoundation  -[__NSArrayM dealloc] + 152

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

CoreFoundation  CFRelease + 524

Выпущен один из элементов массива.

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

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

Код, который вызывает аналогичную ошибку в 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 overrelease
[object1 release];
//when array is released, it will send a release message to object1, too

Ответ 4

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

@property(nonatomic, strong) NSArray *myArray

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

Ответ 5

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

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

@property(strong) NSArray *myArray.