转：Manually symbolicating crash logs with gdb
转： http://www.picsoftware.ca/blog/?p=8
[自：简单步骤：
1，首先对比App的UUID，来确定Crash的版本和App版本是否符合；
2，进入到App和dSYM文件的目录；
3，运行/Developer/Platforms/iPhoneOS.platform/Developer/usr/libexec/gdb/gdb-arm-apple-darwin MyApp.app/MyApp；
4，
set print asm-demangle on
5，
set print symbol-filename on
6，
p/a 0×00015c64
0×00015c64就是想要查询的位置。
]
Manually symbolicating crash logs with gdb
If you’ve ever downloaded a crash report from iTunes Connect for one of your apps there is a good chance that you had a hard time getting any useful information from it. The stack traces in these crash reports don’t contain the meaningful method and file names that would help you track down the bug, they only contain the hexadecimal addresses of the methods. According to this page as long as you have the proper .app and .dSYM files somewhere that Finder can find them Xcode’s Organizer should be able to translate these addresses to the source code method name and line number to which they refer. This is a process called symbolication. In my experience sometimes this works and sometimes it doesn’t.【自：有时候好用，有时候不好用。】 I have tried opening crash reports in the organizer and seen none or in some cases only a few of the symbols coming from my code being properly resolved . This post will describe a method to manually symbolicate these addresses when the Organizer doesn’t work.
As you can see from this screenshot this is a crash log that Xcode only symbolicated a few of the addresses that originated from my code in lines 6 and 7 of the stack trace. Lines 0-5 have not been symbolicated.
So let’s symbolicate these addresses manually. First we need to make sure we have the right .app and .dSYM files. The UUID in the crash log has to match the ones in our .app and .dSYM files. We can check this with a command line utility called dwarfdump.
Running dwarfdump with the –uuid option on our executable gives us this result:
pics‐imac:Downloads pic$ dwarfdump ‐‐uuid MyApp.app/MyApp [自：注意，这里不是.app文件夹，而是在.app下的可执行文件]
UUID: E2D9D241‐37D3‐CE06‐7272‐653B813963E2 (armv6) MyApp.app/MyAppNow we run the same command on our .dSYM file and get this result:
pics‐imac:Downloads pic$ dwarfdump ‐‐uuid MyApp.app.dSYM
UUID: E2D9D241‐37D3‐CE06‐7272‐653B813963E2 (armv6)
MyApp.app.dSYM/Contents/Resources/DWARF/MyAppGood, they match, so we can now check if they are the same as the UUID in the crash log. This can be found in the Binary Images section of the crash log as you can see in this screenshot.
You’ll notice they aren’t in the same format (the one in the crash log doesn’t have the dashes) but that doesn’t matter, as long as the numbers are the same everything is ok.
Now we know we have the .app and .dSYM files that match our crash log so we can launch gdb and start symbolicating. Make sure to use the arm version of gdb which is typically found at:/Developer/Platforms/iPhoneOS.platform/Developer/usr/libexec/gdb/gdb-arm-apple-darwin
pics-imac:Downloads pic$/Developer/Platforms/iPhoneOS.platform/Developer/usr/libexec/gdb/gdb-arm-apple-darwin MyApp.app/MyApp
You may see some warnings about not being able to read symbols for a bunch of frameworks but this is ok. We use the ‘p/a’ command in gdb to symbolicate the addresses from our crash log. Let’s start with the first unsymbolicated address on line 5 of the stack trace.
5 MyApp 0x0002b0ee 0x0002b0ee
Type this ate the gdb prompt:
(gdb) p/a 0x0002b0ee
The result is:
$1 = 0x2b0ee <_ZN7MyAppBase5touchEP8_touch_ts+14>We can probably figure out what method this address is referring to from that but it is still a little ugly. There must be a way to tell gdb to make it nicer for us. After a quick search I found this site that explains some gdb print settings:
http://www.delorie.com/gnu/docs/gdb/gdb_58.html
One that looks promising is:
set print asm-demangle on
Print C++ names in their source form rather than their mangled form, even in assembler code printouts such as instruction disassemblies. The default is off.
Let’s turn it on and see what happens.
(gdb) set print asm-demangle on
(gdb) p/a 0x0002b0ee
And now the result is:
$2 = 0x2b0ee <MyApp::touch(_touch_t*, short)+14>This is much better, we can now see the class name, method name, parameters, and an offset. The only other thing I would like to see is the source code file name and line number just like a properly symbolicated crash log in the Organizer would show. After checking the website with the gdb print settings I found one that looks like it might do what I want:
set print symbol-filename on
Tell GDB to print the source file name and line number of a symbol in the symbolic form of an address.
Let’s try it.
(gdb) set print symbol-filename on
(gdb) p/a 0x0002b0ee
This is the result we get:
$3 = 0x2b0ee <MyApp::touch(_touch_t*, short)+14 at
/Users/pic/Dev/MyApp/Source/MyApp.cpp:307>Perfect! So now we can check the rest of the addresses in the crash log to get the full stack trace and find out exactly where the crash occurred.
(gdb) p/a 0x0006840a
$4 = 0x6840a <Container::touch(_touch_t*, short)+188 at
/Users/pic/Dev/MyApp/Source/widgets/Container.cpp:227>
(gdb) p/a 0x000400ac
$5 = 0x400ac <PuzzleView::touch(_touch_t*, short)+4 at
/Users/pic/Dev/MyApp/Source/PuzzleView.cpp:135>
(gdb) p/a 0x0006840a
$6 = 0x6840a <Container::touch(_touch_t*, short)+188 at
/Users/pic/Dev/MyApp/Source/widgets/Container.cpp:227>
(gdb) p/a 0x0002e216
$7 = 0x2e216 <Keyboard::touch(_touch_t*, short)+554 at
/Users/pic/Dev/MyApp/Source/widgets/Keyboard.cpp:333>
(gdb) p/a 0x0003aa9a
$8 = 0x3aa9a <Grid::keypress(Keyboard*, wchar_t, touch_t)+1114 at
/Users/pic/Dev/MyApp/Source/Grid.cpp:730>
(gdb) q
pics-imac:Downloads pic$Now we know the crash was at line 730 in Grid.cpp and we can go find the bug.
It would be nice if Xcode’s Organizer would just work all the time, but it has been my experience that sometimes for whatever reason it just doesn’t, even if you have the right .app and .dSYM files. In those cases I find this method to be very useful.
Happy debugging!
＋＋＋＋＋