在iOS 6-7的崩溃日志中，使用atos计算崩溃地址对应的符号会出现问题。一个解决方法是使用dwarfdump命令来获取符号信息，而无需进行任何计算。具体命令如下：dwarfdump --arch armv7 myApp.dSYM --lookup 0xaabbccdd | grep 'Line table'。这种方法在Mountain Lion操作系统上测试通过，可以成功获取iOS 6.1.3版本的崩溃日志的符号信息。然而，根据某些用户的反馈，对于armv7s架构的崩溃日志，dwarfdump命令可能会失败，而使用atos进行手动计算的方法仍然有效。

iOS crash reports: atos not working as expected

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

在处理iOS崩溃报告时，我们经常使用atos命令行工具来将内存地址转换为可读的符号。然而，有时候atos无法按预期工作，导致无法正确地符号化崩溃报告。本文将介绍atos无法正常工作的原因以及解决方法。

问题出现的原因：

原因是由于苹果引入了地址空间布局随机化(Address space layout randomization，ASLR)的安全特性，导致应用的加载地址被随机化。在过去，slide的值与加载地址的值相等，因此上述的计算方法总是有效的。然而，自从iOS 4.3开始，应用的加载地址被随机化，slide的值与加载地址不再相等，导致计算错误。

解决方法：

为了解决这个问题，我们需要重新计算地址，然后再使用atos进行符号化。具体步骤如下：

1. 计算slide的值，slide的值等于LC_SEGMENT cmd中vmaddr的值。可以使用以下命令获取slide的值：

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、stack address和load address后，可以使用以下公式计算符号地址symbol address：

symbol address = slide + stack address - load address

如果以上步骤过于繁琐，也可以直接使用atos -l命令来进行符号化，并由atos自动计算地址。

需要注意的是，如果崩溃报告已经被符号化过，那么地址已经被符号化脚本从Xcode中规范化了。所以要检查stack address是否大于load address，并确保正确地查找Binary Images部分中的元素。

通过重新计算地址，我们可以解决atos无法正常工作的问题。通过获取slide、stack address和load address，然后使用公式symbol address = slide + stack address - load address，我们可以正确地使用atos进行符号化，并找到崩溃报告中的符号信息。

问题的原因是Xcode不支持对OS X应用程序进行符号化，即使有.dSYM文件也不行。

解决方法是使用atos -o MyApp.app/MyApp -arch armv7 -l 0x29000 0x0044e89a命令进行符号化，其中MyApp.app/MyApp是应用程序的路径，0x29000是加载地址，0x0044e89a是堆栈地址。

如果找不到应用程序的路径，可以将'.ipa'文件重命名为'.zip'，解压缩后在Payload文件夹中找到。

如果不确定要使用哪种架构（例如armv7或armv7s），可以在崩溃文件的'Binary Images'部分找到。

如果应用程序不包含调试符号，可以将-o部分替换为.dSYM文件中的符号。

+后面的数字是十进制数，它是堆栈地址 - 加载地址的结果。所以你会发现第一个十六进制数字是后两个数字的和。

这对于调试一个模糊的崩溃日志截图非常有帮助。