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
Ответы
Ответ 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 и прошел через аварийное обновление в субботу. Результаты говорят сами за себя: ![source: imgur.com 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.