我正在查看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指向完全不相关的类中的完全良性的代码行。我再次验证我正在使用我提交给Apple的确切dSYM和IPA。
我的atos命令
/Applications/Xcode.app/Contents/Developer/usr/bin/atos -arch armv7 -o MYAPP.app/MYAPP 0x0004fb26
与/ usr / bin / atos和armv7s相同的结果。
还有其他人遇到过此问题吗?你能给些建议么?感谢。
答案 0 :(得分:98)
更简单的替代方法:您可以使用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),请滚动到崩溃文件的“二进制图像”部分,你可以在那里找到它。
干杯
答案 1 :(得分:90)
你必须计算与atos一起使用的地址,你不能只使用堆栈跟踪中的地址。
symbol address = slide + stack address - load address
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
替换为实际可执行文件的路径。
stack address
是崩溃报告中的十六进制值。
load address
可以是显示在包含您的可执行文件的最前面的Binary Images
部分中的第一个地址。 (通常是第一个条目)。
由于过去slide
的值等于load address
的值,因此总是有效。但是自从苹果公司从iOS 4.3开始引入Address space layout randomization(在不同的版本中),出于安全原因,应用程序加载地址是随机的。
答案 2 :(得分:11)
只需使用dwarfdump:
dwarfdump --arch armv7 myApp.dSYM --lookup 0xaabbccdd | grep 'Line table'
根本无需进行任何计算。
(来自Get symbol by address (symbolicating binary, iOS build))。
答案 3 :(得分:3)
对于那些特定时间没有加载地址值的人,如下所示:
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
它只是读取应用程序的路径,应用程序名称,堆栈地址以及&#34; +&#34;之后的值。 signal(十进制值)然后找到要运行atos命令的加载地址的值。