Сбой iOS без ошибки или трассировки стека

Question

Трудно отследить сбой в приложении для iPad.Трудность на самом деле связана с тем, что при сбое приложения нет ошибок или трассировки стека.Он просто уходит, как Кейзер Созе, «И вот так, пуф. Он ушел».

Я повторил сбой на симуляторе и устройстве.Журналов устройств нет, в консоли ничего нет и т. Д.

Я знаю, что во время сбоя некоторые CoreGraphics операции выполняются в фоновом потоке.Как правило, три или около того NSOperations запускают некоторые сочетания изображений.

Смешивание состоит из вызовов CGContext * (DrawImage, SetBlendMode, SetAlpha и т. Д.).NSOperation обращается к делегату в главном потоке, чтобы обработать изображение и установить его на UIImage, так что это не должно быть конфликт основного потока пользовательского интерфейса, но я не буду ничего сбрасывать со счетов в этот момент.

Есть ли какие-то хитрости Xcode, которые мне не хватает, чтобы точно отследить, что происходит?Или, по крайней мере, лучше понять, в чем проблема?

РЕДАКТИРОВАТЬ Я запустил приложение в инструментах, отслеживающих использование памяти, и вижу, что оно довольно стабильно, около 2 МБ.Так что не думайте, что это проблема с памятью.Но после рассмотрения, этот устойчивый 2-мегабайтный камень кажется аномально низким.Есть ли вероятность, что Instruments не получает распределение ресурсов CoreGraphics?

Answer 1

Попробуйте прочитать регистры.

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

Сначала перейдите на вкладку «Исключения» и «Добавить точку останова исключения» с помощью + в левом нижнем углу.

Затем, когда приложение завершает работу, нажмите «0 objc_exception_throw» в разделе 1.

Наконец, в консоли введите:

• регистр прочитан (вы должны получить список регистров)

• po $ rax (обычно исключение составляет 'rax')

  (вы должны увидеть вывод исключения на консоли)

Надеюсь, это поможет.

Answer 2

Из-за отсутствия лучшего решения и, если оно неочевидно, добавьте NSLogs в свое приложение, чтобы обвести кружок, где это происходит, а затем углубиться оттуда через контрольные точки и / или дополнительные журналы.

Answer 3

Супер поздний ответ, но я обнаружил, что использование try / catch помогает получить информацию, когда я не могу получить трассировку стека и мое приложение извлекает Keizer Soze.

@try
{
  // suspected code causing crash/errors
}
@catch (NSException *exception)
{
  NSLog(@"Exception: %@", exception);
}

Answer 4

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

Неправильное подключение приводит к сбою приложения без ошибок или трассировки стека.

Мне интересно, что случилось с ошибкой this class is not key value coding-compliant for the key, которая использовалась в более старых версиях XCode.

Answer 5

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

Answer 6

В моем случае это произошло из-за освобождения объекта. Обычно это будет сообщение, отправленное на освобожденный экземпляр или что-то в этом роде, но это не так. Я проверил журналы iPhone и нашел это: KERN_INVALID_ADDRESS, который я гуглил и наткнулся на это: KERN_INVALID_ADDRESS

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

Надеюсь, это поможет будущим посетителям.