Xcode - перерыв в исключении, но нет пригодных для использования символов

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

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

Исключение:

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

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

StackTrace

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

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

Как я читаю эту трассировку стека:

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

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

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


person edelaney05    schedule 18.05.2013    source источник
comment
Вы изучили массив, переданный в -controllerDidChangeContent:, чтобы проверить, о чем говорит текст причины исключения?   -  person trojanfoe    schedule 18.05.2013
comment
-controllerDidChangeContent: исходит из протокола NSFetchedResultsControllerDelegate, а аргументом является экземпляр FRC, выполняющий обратный вызов. Итак, массив не передается (если только я ужасно неправильно понял ваш вопрос; если это так, то мне очень жаль!)   -  person edelaney05    schedule 18.05.2013
comment
Если вы хотите просмотреть переменные одного фрейма, перейдите к этому фрейму. Вы находитесь в кадре 12 на изображении, щелкните кадр 1, откройте панель просмотра переменных в области отладки и посмотрите, найдете ли вы изменяемый массив. Но в этом случае, как сказал edelaney05, лучше, если вы проверите свой принесенный контроллер.   -  person Jano    schedule 18.05.2013
comment
@Jano это проблема! Когда я смотрю на любой из кадров с 11 по 1, все, что я получаю, это ассемблер.   -  person edelaney05    schedule 18.05.2013
comment
frame select 9 следует изменить фрейм (или использовать мышь в пользовательском интерфейсе, как отметил @Jano. Вы получите ассемблер, потому что у вас нет исходного кода. Это ожидаемо. Я думаю, возможно, frame variable не работает по той же причине (вы не у вас есть источник со всеми именами переменных), но не уверен. Как только вы окажетесь в правильном фрейме, вы сможете сделать po 0x123456 для ссылки на объекты в этом фрейме. Я бы установил точку останова на последнем месте в вашем код до того, как возникнет проблема, и проверьте данные, которые использует представление макета, потому что в некоторых случаях они кажутся странными (выпущено?)   -  person Dad    schedule 24.05.2013


Ответы (1)


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

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

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

трассировка стека со включенными методами

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

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

person edelaney05    schedule 28.05.2013