查看.app,和.dSYM与崩溃日志是否一致的方法：
输入命令:
dwarfdump ‐‐uuid MyApp.app/MyApp
返回内容:
UUID: E2D9D241‐37D3‐CE06‐7272‐653B813963E2 (armv6) MyApp.app/MyApp
输入命令:
dwarfdump ‐‐uuid MyApp.app.dSYM
返回内容
UUID: E2D9D241‐37D3‐CE06‐7272‐653B813963E2 (armv6)MyApp.app.dSYM/Contents/Resources/DWARF/MyApp
对比结果是否一致.
基本步骤，我们已了解的
1. 发布版本时，将.app与.dSYM保存，记录下与发布的.ipa包的对应关系；
2. 从设备/友盟/itunes获得crash log后，拖拽到xcode的organizer中查看；
3. 若backtrace信息完整，参考此信息进行分析修改即可；
4. 若backtrace信息不完整，只有16进制地址，那么使用以下步骤来查看在我们程序中哪里出了错。
像这样，请看下页：
0 libsystem_kernel.dylib 0x36400060 0x363ff000 + 4192
1 libdispatch.dylib 0x3712b124 0x3711e000 + 53540
2 libdispatch.dylib 0x3712b154 0x3711e000 + 53588
3 libxpc.dylib 0x37df189a 0x37dee000 + 14490
4 SystemConfiguration 0x31158be6 0x3112f000 + 170982
5 SystemConfiguration 0x31159d56 0x3112f000 + 175446
6 SystemConfiguration 0x31142aee 0x3112f000 + 80622
7 SystemConfiguration 0x31143f7a 0x3112f000 + 85882
8 dfcft 0x00144384 0x1000 + 1323908
9 dfcft 0x00003d42 0x1000 + 11586
10 dfcft 0x00006102 0x1000 + 20738
11 UIKit 0x378d67e4 0x3789b000 + 243684
12 UIKit 0x378d03b6 0x3789b000 + 218038
13 UIKit 0x3789e91a 0x3789b000 + 14618
14 UIKit 0x3789e3b8 0x3789b000 + 13240
15 UIKit 0x3789dd26 0x3789b000 + 11558
16 GraphicsServices 0x30cd0dec 0x30ccc000 + 19948
17 CoreFoundation 0x344c954c 0x3443c000 + 578892
18 CoreFoundation 0x344c94ee 0x3443c000 + 578798
19 CoreFoundation 0x344c833c 0x3443c000 + 574268
20 CoreFoundation 0x3444b4d6 0x3443c000 + 62678
21 CoreFoundation 0x3444b39e 0x3443c000 + 62366
22 UIKit 0x378cf450 0x3789b000 + 214096
23 UIKit 0x378cc73c 0x3789b000 + 202556
24 dfcft 0x00002d94 0x1000 + 7572
25 dfcft 0x00002d14 0x1000 + 7444
GDB步骤
1. 找到各个线程中（以thread 0为主），我们应用程序名称，比如dfcft/EMT_iPad/东方财富通/<乱码的东方财富通>所对应的行，获取名称后的那列的十六进制值。
…
7 SystemConfiguration 0x31143f7a 0x3112f000 + 85882
8 dfcft 0x00144384 0x1000 + 1323908
9 dfcft 0x00003d42 0x1000 + 11586
10 dfcft 0x00006102 0x1000 + 20738
11 UIKit 0x378d67e4 0x3789b000 + 243684
…
23 UIKit 0x378cc73c 0x3789b000 + 202556
24 dfcft 0x00002d94 0x1000 + 7572
25 dfcft 0x00002d14 0x1000 + 7444
2. 将原有的.app 与.dSYM放在同一个文件夹下，开启终端，cd 到此文件夹下，下面例子中，我们的应用dfcft.app和.dSYM文件都放在了~/Documents/TestdSYM/文件夹下。
emmatoMacBook:Documents em$ cd TestdSYM/
emmatoMacBook:TestdSYM em$ ls
dfcft.app
dfcft.app.dSYM
dfcft_2011-11-17-222717_lwx-ios435.crash
dfcft_2011-11-17-235921_lwx-ios435.crash
3 使用gdb命令运行此程序，提示见下面列出的命令和系统的响应。
由于不是在标准的运行环境中运行的，因此只能使用gdb查看我们应用中自身定义的量，下面的一些warning说明玲，系统的像UIKit，CoreTelephony这样的软件包在这里运行，gdb没有找到，这种系统级动态库的地址我们无法解码。
emmatoMacBook:TestdSYM em$ gdb dfcft.app
GNU gdb 6.3.50-20050815 (Apple version gdb-1705) (Tue Jul 5 07:28:08 UTC 2011)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "x86_64-apple-darwin"...
warning: Unable to read symbols from "UIKit" (not yet mapped into memory).
…
warning: Unable to read symbols from "CoreTelephony" (not yet mapped into memory).
Reading symbols for shared libraries ................ done
warning: Inconsistent DBX_SYMBOL_SIZE (nlist record size was 16, is now 12 with /Users/em/Documents/TestdSYM/dfcft.app/dfcft)
(gdb)
4 以上步骤完成后就进入了gdb调试状态，我们可以通过info line命令来获得Crash Log中一些地址究竟对应着什么函数。
(gdb) info line *0x00134cf4
Line 1685 of "/Users/jerrysdfhe/Desktop/engine/ASIHTTPRequest.m" starts at address 0x134cd0 <-[ASIHTTPRequest updateDownloadProgress]+400> and ends at 0x134d0c <-[ASIHTTPRequest updateDownloadProgress]+460>.
上例中可见，我们所查看的地址 *0x00134cf4对应着的是ASIHTTPRequest.m文件中的updateDownloadProgress函数。
重复第四步，获取第一步中绿色标注的各行的所列出的地址信息，
即可通过这种方法手工再现Crash Log中的BackTrace详细信息，为我们找寻引起Crash的原因提供线索。
相关编译选项设置
当前xcode工程中build settings默认设置strip style选项为All Symbols，也就是所有的symbols都会被删除，这是导致我们的crash Log中没有函数名的根源。
但这个选项的好处是编译出来的文件小，剔除了程序运行所不必须的记录。
如果是单纯的测试版本，并且希望追踪Crash问题产生的原因，可以将此选项设置为Debugging Symbols，那么只会将我们的Debug函数，比如NSLog等输出信息的Symbols剔除。