iOS崩溃报告：atos无法按预期工作-Java 学习之路

我正在查看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输出甚至不是来自我提交给Apple的确切dSYM和IPA的同一个类 .

我的atos命令

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

与/ usr / bin / atos和armv7s的结果相同 .

还有其他人遇到过这个问题吗？你能给些建议么？谢谢 .

4 回答

11
你必须计算与atos一起使用的地址，你不能只使用stacktrace中的地址 .
```
symbol address = slide + stack address - load address
```
- slide 值是 LC_SEGMENT cmd 中的 vmaddr 的值（大部分是 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 的值，因此总是有效 . 但是由于Apple从iOS 4.3开始引入Address space layout randomization（在不同的版本中），出于安全原因，应用程序加载地址是随机的 .
回复于 2024-04-28T02:20:20+08:00
95
一个更简单的替代方案：您可以使用 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），请滚动到崩溃文件的“二进制图像”部分，您可以在其中找到它 .

干杯
回复于 2024-04-28T02:20:20+08:00
3
只需使用dwarfdump：
```
dwarfdump --arch armv7 myApp.dSYM --lookup 0xaabbccdd | grep 'Line table'
```
根本不需要做任何计算 .

（来自Get symbol by address (symbolicating binary, iOS build)） .
回复于 2024-04-28T02:20:20+08:00

对于某些时候没有加载地址值的人，如下所示：

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命令的加载地址的值 .

回复于 2024-04-28T02:20:20+08:00

iOS崩溃报告：atos无法按预期工作

4 回答

相关问题