Альтернатива NSZombie

Я пытаюсь отладить сбой EXC_BAD_ACCESS с помощью NSZombie. Мое приложение создает много больших объектов, и с включенным NSZombie они не выпускаются, что приводит к сбою приложения в считанные секунды. Это означает, что я не могу даже вызвать сбой EXC_BAD_ACCESS до того, как приложение вылетит из-за нехватки памяти.

Есть ли альтернатива? Могу ли я включить NSZombie для определенного файла, а не для всего проекта? Как еще я мог бы отладить этот сбой (я знаю, что это вызвано UIGestureRecognizer, но я часто использую их, поэтому это не сужает проблему значительно).

Спасибо.

Правка: спасибо за совет. Я думаю, что, возможно, я решил проблему и сообщу после дополнительного тестирования.

Редактировать 2: решить проблему самостоятельно, но выбрать ответ, который кажется хорошим решением для любых подобных проблем в будущем.


ios objective-c memory nszombie
person Community    schedule 03.11.2014    source источник
comment
Симулятор может обрабатывать гораздо больше памяти, чем реальное устройство. Можешь попробовать на симуляторе?   -  person rmaddy    schedule 03.11.2014
comment
@rmaddy С этим тоже не повезло. Он выделяет около 100 мб памяти и вылетает.   -  person    schedule 03.11.2014
comment
Если у вас возникли проблемы с зомби, первое, что нужно сделать, это запустить Analyzer и тщательно изучить выдаваемые предупреждения. Есть хороший шанс, что он найдет вашу проблему.   -  person Hot Licks    schedule 03.11.2014
comment
@HotLicks Думаю, я действительно решил это! Собираюсь провести еще несколько тестов, прежде чем подтвердить, поскольку это было нелегко воспроизвести.   -  person    schedule 03.11.2014
comment
@kmcgrady в вашем Dealloc, возможно, вам удастся заменить isa вашего объекта указателем на класс зомби, чтобы выполнить проверку зомби в одном файле. Может быть. Не пробовал.   -  person bbum    schedule 04.11.2014

Ответы (2)


arrow_upward
2
arrow_downward

Все, о чем я могу думать, это реализовать это вручную; создайте прокси-контейнер, который содержит объект типа id и назначит его как -forwardingTargetForSelector:, а также заставит его отвечать на -isKindOfClass: и т. д.

Отключите ARC для прокси-сервера, чтобы он сохранял себя в течение init и проверял свой собственный retainCount при назначении цели пересылки.

Если счетчик равен 1, создайте исключение или зарегистрируйте предупреждение или что-то еще.

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

Для возможных бонусных баллов сохраните [NSThread callStackSymbols] где-нибудь (возможно, на диске) во время модуля прокси, чтобы вы могли хотя бы узнать, где был создан неправильно управляемый объект.

person Tommy    schedule 03.11.2014
comment
Очень интересная идея. Я собираюсь изучить это сейчас. - person ; 03.11.2014
comment
К счастью, я обнаружил проблему с помощью пробной ошибки примерно через 15 минут после того, как вы опубликовали это. Я предполагаю, что страх перед попыткой реализовать это подстегнул меня! Хотя идея отличная, спасибо. - person ; 04.11.2014

arrow_upward
-3
arrow_downward

NSZombies был/есть для приложений, которые используют собственное управление памятью. Если ваше приложение использует ARC, это не поможет.

Создайте новую точку останова: все исключения

Обычно это должно показать вам, где вы вызываете плохой доступ.

person Helge Becker    schedule 03.11.2014
comment
Спасибо, я пробую это сейчас - и вы правы, я использую ARC. - person ; 03.11.2014
comment
Это неправда. NSZombies идеально подходит для использования с ARC. - person Nikolai Ruhe; 03.11.2014
comment
К сожалению, это не помогло. Точка останова исключения не поймала его раньше. - person ; 03.11.2014
comment
Установка точки останова исключения не поможет в случае EXC_BAD_ACCESS. - person Nikolai Ruhe; 03.11.2014
comment
NSZombie можно использовать в любое время, когда можно сослаться на освобожденный объект, что вполне возможно в ARC. ARC не избавляется от сохранения/релизов/аллоков/деаллоков/авторелизов, он просто добавляет их для вас. - person Morgan Chen; 03.11.2014