Как читать objective-c трассировки стека

У меня есть следующая трассировка стека:

0 MyApp 0x000833a3 +[TFCrashHandler backtrace] + 26
1 MyApp 0x000836bd TFSignalHandler + 28
2 libsystem_c.dylib 0x33eac727 _sigtramp + 34
3 ??? 0x00000002 0x0 + 2
4 MyApp 0x000803f1 msgpack_unpack_next + 112
5 MyApp 0x0007faeb +[MessagePackParser parseData:] + 74
6 MyApp 0x0007f84b -[NSData(NSData_MessagePack) messagePackParse] + 26
7 MyApp 0x000254c3 +[Http get:params:cacheMins:msgPack:complete:] + 146
...

И мне интересно, как его прочитать:

  • Предполагаю, что я иду снизу вверх, например, строка 7, называемая строкой 6, называемой строкой 5 и т.д.
  • Что означает "+ 112" в строке 4? Это номер строки в файле кода, где он разбился?
  • Что делает '???' на линии 3 означает?

Спасибо большое

ОТВЕТЫ

Ответ 1

0 MyApp 0x000833a3 +[TFCrashHandler backtrace] + 26

Сбой возник из +[TFCrashHandler backtrace] + 26; от любой команды, упавшей в этом месте символа + 26 байт.

Если это действительно нижняя часть вашей трассировки стека, и она разбилась там, то TCrashHandler скрывает реальный сбой. Настоящая авария выглядит как пара кадров выше.

1 MyApp 0x000836bd TFSignalHandler + 28

TFSignalHandler - это то, что называется + backtrace.

2 libsystem_c.dylib 0x33eac727 _sigtramp + 34

Ewww... сигнальный батут. Приложение получило сигнал, и батут был настроен на вызов TFSignalHandler().

Бывают ситуации, когда обработчик сигнала может быть вызван на случайный поток. То есть существует незначительная вероятность того, что эта конкретная авария не имеет ничего общего с парсером и все, что связано с крушением в другом месте. Однако, не зная больше о синтаксическом анализаторе, я бы поставил вопрос о том, затвердевает ли он от вредоносного ввода (что может привести к сбою в этом случае).

3 ??? 0x00000002 0x0 + 2

Стек был недопустим. Отбой. Бессмысленно. Лучший случай; выпад из оптимизации компилятора. Худший случай; кто-то извергался в стеке, а механизм backtrace не мог понять, что происходит (очень маловероятно - обычно, стекольная пупка брызгает до такой степени, что предотвращает полную обратную трассировку).

4 MyApp 0x000803f1 msgpack_unpack_next + 112

Ооооочень... хитрый. Кто-то использует C для разбора материала. И он разбился. Какая бы ни была инструкция, 112 байт от точки входа в функцию запустили стрелу. Но на самом деле это не так, потому что он назывался обработчиком сигналов и был обработан этим; который по-прежнему является бумом, но обработчик сигналов эффективно уничтожает дополнительные судебные доказательства.

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

5 MyApp 0x0007faeb +[MessagePackParser parseData:] + 74

MessagePackParser разбирался, когда дела шли ужасно неправильно.

6 MyApp 0x0007f84b -[NSData(NSData_MessagePack) messagePackParse] + 26
7 MyApp 0x000254c3 +[Http get:params:cacheMins:msgPack:complete:] + 146

Ahh... да... кто-то сделал захват некоторых данных из HTTP, и он был искажен, что вызвало сбой.

Нижняя линия; парсер получил фиктивный вход и разбился. Был обработчик сигнала, который пытался помочь, создав обратную линию, но, по-видимому, на самом деле не раскрыл больше информации. Альтернатива длинным выстрелом заключается в том, что сигнал генерировался где-то в другом месте, и этот поток был выбран случайным образом для его обработки. Если вы можете последовательно воссоздать этот сбой, случай случайного потока будет маловероятным.

Если у вас нет захвата входных данных или можно каким-то образом догадаться, как может произойти сбой в msgpack_unpack_next(), вам не повезло, не предоставив больше информации.

Ответ 2

"???" это то, что невозможно идентифицировать, вероятно, код, который был скомпилирован без символов, но может также быть чем-то другим.

Ответ 3

Это номера строк в файле реализации. И hex - это указатель в памяти на вызов линии.