Символизация трассировки стека без сбоя

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

Если у вас есть dSYM для той версии приложения, откуда берется трассировка стека, вы действительно можете превратить это во что-то полезное. Прочтение этого ответа здесь приведет к эта статья, которая мне очень помогла. У меня была эта строка поверх трассировки стека:

0    MyApp                           0x000000010010da68 MyApp + 236136
                                     ^ stack address            ^ symbol offset

У вас есть два варианта, оба связаны с математикой. Если вы выберете atos, вам просто нужно один раз сделать математику, и вы можете просмотреть все шаги с помощью одного вызова.

Использование atos

Чтобы использовать atos, вам нужен адрес стека из трассировки стека, и вам нужно узнать адрес загрузки с помощью некоторой математики:

1. Рассчитайте значение адреса загрузки, вычтя значение смещения символа из значения адреса стека (load address = stack address - symbol offset), конечно, вам нужно преобразовать их на одну базу, чтобы сделать это

   В моем случае это было 0x1000D4000

2. Найдите записи трассировки стека с помощью atos, используя адрес загрузки и адреса стека из трассировки стека с помощью atos -arch <architecture> -o <path to executable inside (!) the dSYM> -l <load address> <stack address 1> <stack address 2> ...

   В моем случае это было atos -arch arm64 -o MyApp.app.dSYM/Contents/Resources/DWARF/MyApp -l 0x1000D4000 0x000000010010da68

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

Использование dwarfdump

Для использования dwarfdump вам потребуется адрес файла, соответствующий адресу стека в трассировке стека.

1. Узнайте значение слайда для архитектуры, откуда берется трассировка стека (см. Получение значения слайда в связанной статье).

   В моем случае это было 0x100000000 для 64-битной версии.

2. Преобразуйте значение смещения символа (число сразу после MyApp + ... в трассировке стека, 236136 в моем случае) в шестнадцатеричное и добавьте результат в слайд. Номер, который вы получаете сейчас, называется адресом файла (file address = symbol offset + slide).

   В моем случае это привело к 0x100039A68.

3. Найдите записи трассировки стека с помощью dwarfdump, используя адрес файла с dwarfdump --lookup <file address> --arch <architecture> <path to dSYM>

   В моем случае это было dwarfdump --lookup 0x100039A68 --arch arm64 MyApp.dSYM

Я столкнулся с той же проблемой, и этот ответ сработал для меня: https://stackoverflow.com/a/4954949/299262

Вы можете использовать atos для обозначения отдельных адресов, если у вас есть dSYM.

пример команды:

atos -arch armv7 -o 'app name.app'/'app name' 0x000000000

Я не думаю, что это возможно. [NSThread callStackSymbols] возвращает адрес памяти функций. Это невозможно обозначить без сброса памяти сразу после сбоя. При сбое адреса у каждого устройства разные. Даже на одном устройстве при перезагрузке телефона адреса менялись после очередного сбоя. Несколько парней упомянули atos, но это для журнала сбоев, а не для callStackSymbols.