Xcode-Break on exception, но никаких полезных символов


Мне нужна помощь в определении магического заклинания, необходимого для получения полезной информации в LLDB.

У меня есть какое-то странное поведение, которое я пытаюсь отладить, и я могу надежно воспроизвести проблему, но я еще не понимаю основную причину. Я заметил, что было вызвано исключение, и поэтому я добавил точку останова исключения в Xcode.

Исключение:

CoreData: error: серьезная ошибка приложения. Исключение было поймано от делегата конференции: NSFetchedResultsController во время вызова - controllerDidChangeContent:. *** - [__NSArrayM objectAtIndex:]: индекс 2 вне границ для пустого массива с userInfo (null)

Итак, с моей точкой останова на месте я получаю следующую трассировку стека:

Трассировка стека

Это выглядит очень полезным! Похоже, что с UICollectionViewFlowLayout для многоразовых представлений заголовков происходит какая-то странность... теперь мне просто необходимо это сделать... о. дерьмо. ждать. Что?

Как я могу проверить тот массив в кадре 1 трассировки стека, который вызывается с индексом out of bound? Могу ли я po <some memory address> в консоли его осмотреть? Я не могу использовать frame variable в консоли LLDB, когда кадры 11 - 1 выбраны (отсюда ).

Способ, которым я читаю эту трассировку стека:

  1. (кадр 14) контроллер fetched results обнаружил изменение контекста управляемого объекта и вызывает его делегат
  2. (кадр 13) делегат FRC, экземпляр FHMemberDirectory, отправьте сообщение -memberDirectoryDidChangeContent:completion: контроллеру вида FHMemberDirectoryViewController, который является подклассом UICollectionViewController
  3. (кадр 12) контроллер вида вызывает -performBatchUpdates:completion: на своем экземпляре UICollectionView
  4. (кадры 10-1) частные вещи Apple, случается, пытаются расклеить представление коллекции на экране; я думаю!

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

На мой нетренированный взгляд, это похоже на ошибку, скрытую в коде Apple, но мне все еще нужно найти способ обойти ее. Суть моей проблемы заключается в понимании того, как получить полезную информацию из консоли LLDB в коде, который не находится под моим непосредственным контролем.
1 4

1 ответ:

Из моих экспериментов и исследований, ответ таков:

Только с LLDB вы не можете получить полезные символы или адреса памяти для проверки.

Тем не менее, вы можете использовать среду выполнения Objective-C для swizzle реализаций методов и перехода в глубокую трассировку стека, что дает вам дескриптор аргументов и возвращаемых значений.

трассировка стека с помощью методов, введенных в систему

Теперь у меня есть доступ к аргументам, переданным в кадрах 3 и 5!

(оказывается, аргумент ...usingData: - это частный класс Apple. Я смог раскопать больше о классе здесь , но ничего сверх полезного. В конце дня я подал радар и попросил помощи в обходе от DTS).