Символизирующая трассировка стека без сбоев

Ответ 1

Я столкнулся с той же проблемой, и этот ответ сработал у меня: fooobar.com/questions/16671/...

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

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

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

Ответ 2

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

Ответ 3

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

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

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

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

Используя atos

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

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

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

• Найдите записи трассировки стека с помощью 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, вам понадобится адрес файла, соответствующий адресу стека в трассировке стека.

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

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

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

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

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

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