Как читать трассировки стека 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 имеется ввиду?

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

Источник

3 ответа

Решение
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

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

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

3 ??? 0x00000002 0x0 + 2

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

4 MyApp 0x000803f1 msgpack_unpack_next + 112

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

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

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

Аааа... да... кто-то взял данные из HTTP, и они были повреждены, что привело к сбою.

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

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

Источник

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

Источник

Это номера строк в файле реализации. А шестнадцатеричный это указатель в памяти на вызов линии.

Источник
Другие вопросы по тегам