iOS 崩溃报告：atos 未按预期工作
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/13574933/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
iOS crash reports: atos not working as expected
提问by George Burdell
I'm looking at a crash report provided by Apple
我正在查看 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
The funny thing is when I use atos to lookup the line of code that corresponds to address locations 0x0006573aand 0x0004fb26I get completely different match. The atos output is not even from the same class that's mentioned in the crash log (MyViewController, MyImageTask). Instead atos points me to totally benign lines of code in a completely unrelated class. I verified again that I'm working with the exact dSYM and IPA that I submitted to Apple.
有趣的是，当我使用 atos 查找与地址位置0x0006573a和0x0004fb26对应的代码行时，我得到了完全不同的匹配。atos 输出甚至不是来自崩溃日志中提到的同一个类（MyViewController、MyImageTask）。相反，atos 指出我在一个完全不相关的类中完全良性的代码行。我再次确认我正在使用我提交给 Apple 的确切 dSYM 和 IPA。
My atos command
我的atos命令
/Applications/Xcode.app/Contents/Developer/usr/bin/atos -arch armv7 -o MYAPP.app/MYAPP 0x0004fb26
Same result with /usr/bin/atos and for armv7s.
与 /usr/bin/atos 和 armv7s 的结果相同。
Has anyone else experienced this issue? Can you please advise? Thanks.
有没有其他人遇到过这个问题？你能给些建议么？谢谢。
回答by Chris
A simpler alternative: you can use the atos -lflag to make it do the maths for you.
一个更简单的选择：您可以使用该atos -l标志让它为您做数学运算。
Say you've got the following line in your crash log that you want to symbolicate:
假设您的崩溃日志中有以下要表示的行：
5 MyApp 0x0044e89a 0x29000 + 4348058
The first hex number is the stack address, and the second hex number is the load address. You can ignore the last number. You don't need to worry about slide addresses either.
第一个十六进制数是堆栈地址，第二个十六进制数是加载地址。您可以忽略最后一个数字。您也无需担心幻灯片地址。
To symbolicate, do the following:
要符号化，请执行以下操作：
atos -o MyApp.app/MyApp -arch armv7 -l 0x29000 0x0044e89a
If you can't find your MyApp.app/MyApp file, rename your '.ipa' file to a '.zip', unzip it, and it'll be in the Payload folder.
如果您找不到 MyApp.app/MyApp 文件，请将您的“.ipa”文件重命名为“.zip”，将其解压缩，它将位于 Payload 文件夹中。
And if you're not sure which architecture to use (for example, armv7 or armv7s), scroll to the 'Binary Images' part of the crash file and you can find it in there.
如果您不确定要使用哪种架构（例如，armv7 或 armv7s），请滚动到崩溃文件的“二进制图像”部分，您可以在那里找到它。
Cheers
干杯
回答by Kerni
You have to calculate the address to use with atos, you can't just use the one in the stacktrace.
您必须计算要与 atos 一起使用的地址，不能只使用堆栈跟踪中的地址。
symbol address = slide + stack address - load address
The
slidevalue is the value ofvmaddrinLC_SEGMENT cmd(Mostly this is0x1000). Run the following to get it:otool -arch ARCHITECTURE -l "APP_BUNDLE/APP_EXECUTABLE" | grep -B 3 -A 8 -m 2 "__TEXT"Replace
ARCHITECTUREwith the actual architecture the crash report shows, e.g.armv7. ReplaceAPP_BUNDLE/APP_EXECUTABLEwith the path to the actual executable.The
stack addressis the hex value from the crash report.The
load addresscan be is the first address showing in theBinary Imagessection at the very front of the line which contains your executable. (Usually the first entry).
该
slide值是vmaddrin的值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段在很前面包含可执行行。（通常是第一个条目）。
Since in the past value of the slidewas equal to value of the load addressthis always worked. But since Apple introduced Address space layout randomizationbeginning with iOS 4.3 (in different variations), the apps loading address is randomized for security reasons.
由于过去的价值slide等于价值，load address这总是有效的。但是由于 Apple从 iOS 4.3 开始引入了地址空间布局随机化（在不同的变体中），出于安全原因，应用程序加载地址是随机化的。
回答by CpnCrunch
Simply use dwarfdump:
只需使用 dwarfdump：
dwarfdump --arch armv7 myApp.dSYM --lookup 0xaabbccdd | grep 'Line table'
No need to do any calculations at all.
根本不需要做任何计算。
(From Get symbol by address (symbolicating binary, iOS build)).
回答by DenninDalke
For whom that certain times doesn't have the value for Load Address like this:
对于某些时间没有像这样的加载地址值的人：
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
I've created a simple bash to help me debug:
我创建了一个简单的 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
It just reads the path for the app, the app name, the stack address, and the value after "+" signal (the decimal value) and then find the value for load address to run atos command.
它只是读取应用程序的路径、应用程序名称、堆栈地址和“+”信号后的值（十进制值），然后找到加载地址的值来运行 atos 命令。
