Отчеты о сбоях iOS: atos не работает должным образом

Я смотрю на отчет о сбое, предоставленный Apple

Hardware Model:      iPhone4,1
Version:         ??? (???)
Code Type:       ARM (Native)
Parent Process:  launchd [1]

Date/Time:       2012-11-18 16:03:44.951 -0600
OS Version:      iOS 6.0.1 (10A523)
Report Version:  104

Exception Type:  EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0x51fe5264
Crashed Thread:  0

Thread 0 name:  Dispatch queue: com.apple.main-thread
Thread 0 Crashed:
0   libobjc.A.dylib                 0x352925b0 objc_msgSend + 16
1   MYAPP                           0x0006573a -[MyViewController(Images) didReceiveImage:context:etag:expires:] + 42
2   MYAPP                           0x0004fb26 -[MyImageTask didReceiveImage:] + 98
3   Foundation                      0x361ac8e8 __NSThreadPerformPerform
4   CoreFoundation                  0x3b37d680 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__
5   CoreFoundation                  0x3b37cee4 __CFRunLoopDoSources0
6   CoreFoundation                  0x3b37bcb2 __CFRunLoopRun
7   CoreFoundation                  0x3b2eeeb8 CFRunLoopRunSpecific
8   CoreFoundation                  0x3b2eed44 CFRunLoopRunInMode
9   GraphicsServices                0x396bc2e6 GSEventRunModal
10  UIKit                           0x3452e2f4 UIApplicationMain
11  MYAPP                           0x0004934a main + 70
12  MYAPP                           0x000492fc start + 36

Самое смешное, что когда я использую atos для поиска строки кода, которая соответствует адресам 0x0006573a и 0x0004fb26, я получаю совершенно другое соответствие. Вывод atos даже не из того же класса, который указан в журнале сбоев (MyViewController, MyImageTask). Вместо этого atos указывает мне на совершенно мягкие строки кода в совершенно не связанном классе. Я снова проверил, что я работаю с теми же dSYM и IPA, которые я отправил в Apple.

Моя команда Атос

/Applications/Xcode.app/Contents/Developer/usr/bin/atos -arch armv7 -o MYAPP.app/MYAPP 0x0004fb26

Тот же результат с /usr/bin/atos и для armv7s.

Кто-нибудь еще сталкивался с этой проблемой? Вы могли бы посоветовать? Благодарю.

Источник

4 ответа

Решение

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

symbol address = slide + stack address - load address

  1. slide значение является значением vmaddr в LC_SEGMENT cmd (В основном это 0x1000). Запустите следующее, чтобы получить его:

    otool -arch ARCHITECTURE -l "APP_BUNDLE/APP_EXECUTABLE" | grep -B 3 -A 8 -m 2 "__TEXT"

    замещать ARCHITECTURE с фактической архитектурой отчет о сбое показывает, например, armv7, замещать APP_BUNDLE/APP_EXECUTABLE с путем к фактическому исполняемому файлу.

  2. stack address шестнадцатеричное значение из отчета о сбое.

  3. load address может быть это первый адрес, отображаемый в Binary Images раздел в самом начале строки, который содержит ваш исполняемый файл. (Обычно первая запись).

Так как в прошлом значение slide был равен значению load address это всегда работало. Но поскольку Apple представила рандомизацию размещения адресного пространства, начиная с iOS 4.3 (в разных вариациях), адрес загрузки приложений рандомизирован по соображениям безопасности.

Источник

Более простая альтернатива: вы можете использовать atos -l флаг, чтобы он сделал математику для вас.

Допустим, в вашем журнале сбоев есть следующая строка, которую вы хотите обозначить символом:

5   MyApp                   0x0044e89a 0x29000 + 4348058

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

Чтобы символизировать, сделайте следующее:

atos -o MyApp.app/MyApp -arch armv7 -l 0x29000 0x0044e89a

Если вы не можете найти файл MyApp.app/MyApp, переименуйте ваш файл.ipa в ".zip", разархивируйте его, и он будет в папке Payload.

И если вы не уверены, какую архитектуру использовать (например, armv7 или armv7s), прокрутите до части "Двоичные изображения" файла сбоев, и вы сможете найти ее там.

ура

Источник

Просто используйте dwarfdump:

dwarfdump --arch armv7 myApp.dSYM --lookup 0xaabbccdd | grep 'Line table'

Нет необходимости делать какие-либо расчеты вообще.

(Из символа "Получить по адресу" (символьный двоичный файл, сборка iOS)).

Источник

Для кого это определенное время не имеет значения для адреса загрузки, как это:

Jan 14 11:02:39 Dennins-iPhone AppName[584] <Critical>: Stack Trace: (
    0   CoreFoundation                      0x2c3084b7 <redacted> + 150
    1   libobjc.A.dylib                     0x39abec8b objc_exception_throw + 38
    2   CoreFoundation                      0x2c21cc35 CFRunLoopRemoveTimer + 0
    3   AppName                             0x0005a7db AppName + 272347

Я создал простой bash, чтобы помочь мне отладить:

#! /bin/bash
read -p "[Path] [App Name] [Stack Address] [DecimalSum] " path appName stackAddress decimalSum
loadAddress=`echo "obase=16;ibase=10;$((stackAddress-decimalSum))" | bc`
atos -o $path/Payload/$appName.app/$appName -l $loadAddress $stackAddress -arch armv7

Он просто читает путь к приложению, имя приложения, адрес стека и значение после сигнала "+" (десятичное значение), а затем находит значение для адреса загрузки для запуска команды atos.

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