方法1：用工具直接獲取 iPhone 設備上 /var/mobile/Library/Logs/CrashReporter 中的 Crash 報告文件。（Mac 下用 PhoneView/iTools/iExplorer，Windows下用、iFunBox、iTools、91助手等）。
方法2：如果 iTunes 同步，則同步後Crash日誌會同步到電腦上，把以下目錄中的Crash提取打包即可：
Mac OS X：~/Library/Logs/CrashReporter/MobileDevice
Windows XP：C:\Documents and Settings\Application Data\Apple computer\Logs\CrashReporter
Windows 7/Vista: C:\Users\AppData\Roaming\Apple computer\Logs\CrashReporter/MobileDevice/
分析log的方法：
你可以在文章中所提到的目錄中找不到symbolicatecrash，因爲它在新的SDK中被移到了這裏：
/Developer/Platforms/iPhoneOS.platform/Developer/Library/PrivateFrameworks/
DTDeviceKit.framework/Versions/A/Resources/symbolicatecrash
大概說明一下是:
1.同步應用程序以後,找到你要查看的日誌文件,日誌文件對應mac的位置,xp\vista的位置.
2.發現日誌文件都是看不懂的16進制,如何進行轉換成我們看得懂的內容.
3.使用命令行工具 "symbolicatecrash"來進行轉換,可以把 工具複製到任何地方都可以調用的路徑:sudo cp/Developer/Platforms/iPhoneOS.platform/Developer/Library/PrivateFrameworks/DTDeviceKit.framework/Versions/A/Resources/symbolicatecrash /usr/local/bin/
4.講了 "symbolicatecrash" 工具怎麼用.一般只要:symbolicatecrash report.crashMobileLines.app.dSYM > report-with-symbols.crash,就可以了
5.注意說明的是,你在用Xcode debug打包的時候,會生成兩個東西,一個是XXX.app,另一個是XXX.app.dSYM,這兩個是相對應的,與我寫的第4點裏的 MobileLines.app.dSYM是對應起來的.這裏的日誌文件必須是你打包的那個版本,不然就沒有解析出你的日誌文件了.通俗的說,你安裝到手機上的app和這個dSYM,是配對的,如果你想要看這個手機上的日誌文件,那你必須保存對應的dSYM文件去解析日誌文件.每一次重新打包都會重新生成dSYM文件.
6.好了,你可以根據你的 report-with-symbols.crash,日誌文件來看看你的程序哪裏出問題了
Sometimes programs crash. This annoys users and developers alike. Users are frustrated because they cannot use crashing software, developers are frustrated because they have to hunt bugs instead of doing something creative and rewarding. How do we communicate if an iPhone application crashes?
I’ll start with a disclaimer. I’m not sure whether the information provided in this post is covered by iPhone Developer Program NDA or not. If it is, the post will be removed. Secondly, this post is a result of googling, so I haven’t invented anything new here.
Working with crash logs typically involves certain interaction between developers and users, unless they are automagically sent to the developer. First of all, the user should get the crash log and send it to the developer, who should examine it, find the bug and fix it.
iPhone OS and Mac OS X are remarkably similar architectures. Both store crash logs to help identify crashing bugs. The difference between the two is how users retrieve them. On Mac OS X every user has unrestricted access to crash logs related to the applications she runs. The iPhone does not even have a file browser. What to do? iTunes comes to the rescue.
Whenever you synchronize your iPhone or iPod Touch, all the crash logs are transferred to your computer. Here are their locations:
Mac OS X:~/Library/Logs/CrashReporter/MobileDevice/<DEVICE_NAME>
Windows XP:C:\Documents and Settings\<USERNAME>\Application Data\Apple computer\Logs\CrashReporter/<DEVICE_NAME>
Windows Vista:C:\Users\<USERNAME>\AppData\Roaming\Apple computer\Logs\CrashReporter/MobileDevice/<DEVICE_NAME>
The log file names start with application name and have the extension “crash”. They are just plain text files and can be sent by e-mail in original or zipped form, or even copy-pasted into your e-mail program.
The second part is trickier. Both Apple and common sense suggest that all AppStore binaries are shipped with stripped symbols. If you ever saw a crash log like this, read on:
Thread 0 Crashed:0 libobjc.A.dylib 0x300c87ec 0x300bb000 + 552761 MobileLines 0x00006434 0x1000 + 215562 MobileLines 0x000064c2 0x1000 + 216983 UIKit 0x30a740ac 0x30a54000 + 1312444 UIKit 0x30a66110 0x30a54000 + 740005 UIKit 0x30a6565c 0x30a54000 + 712606 GraphicsServices 0x3169b0b4 0x31696000 + 206607 GraphicsServices 0x3169d818 0x31696000 + 307448 IOMobileFramebuffer 0x31f3e8f8 0x31f3d000 + 63929 com.apple.framework.IOKit 0x30f342b8 0x30f30000 + 1708010 CoreFoundation 0x3025ced4 0x30229000 + 21269211 CoreFoundation 0x3025bed6 0x30229000 + 20859812 CoreFoundation 0x3025b584 0x30229000 + 20621213 GraphicsServices 0x316998e4 0x31696000 + 1456414 UIKit 0x30a5e308 0x30a54000 + 4173615 UIKit 0x30a671dc 0x30a54000 + 7830016 MobileLines 0x00002090 0x1000 + 424017 MobileLines 0x0000202c 0x1000 + 4140In a nutshell, it contains function addresses and offsets instead of function names and line numbers. The structure is obvious, but, to be honest, I don’t know what“MobileLines 0×00006434 0×1000 + 21556″ is, even though I have all the source code. Thanks to Apple Developer Tools and to Craig Hockenberry whowrote about it, we have a perfect solution called symbolicatecrash.
I copied it to/usr/local/bin/so that I can run it whenever I want without trying to remember its original location (you may prefer a symbolic link):
$ sudo cp /Developer/Platforms/iPhoneOS.platform/Developer/Library/Xcode/Plug-ins/iPhoneRemoteDevice.xcodeplugin/Contents/Resources/symbolicatecrash /usr/local/bin/
Running this script with the-h option provides the minimal help:
$ symbolicatecrash -h
usage:
symbolicatecrash [-Ah] LOGFILE [SYMBOL_PATH ...]
Symbolicates a crashdump LOGFILE which may be "-" to refer
to stdin. By default, all heuristics will be employed
in an attempt to symbolicate all addresses. Additional
symbol files can be found under specified directories.
Options:
-A Only symbolicate the application, not libraries
-h Display this message
-v Verbose
To add symbols to the crash log you need the dSYM file generated by the linker when you compiled your application for AppStore. In other words, when you build for AppStore you should keep the dSYM package in a safe place backed up by Time Machine. This is very important.You should keep a copy of the dSYM for each version of your application ever shipped. If you have the package, translating code offsets to function names with line numbers has never been easier:
$ symbolicatecrash report.crash MobileLines.app.dSYM > report-with-symbols.crash
Here is the result:
Thread 0 Crashed:0 libobjc.A.dylib 0x300c87ec objc_msgSend + 201 MobileLines 0x00006434 -[BoardView setSelectedPiece:] (BoardView.m:321)2 MobileLines 0x000064c2 -[BoardView touchesBegan:withEvent:] (BoardView.m:349)3 UIKit 0x30a740ac -[UIWindow sendEvent:] + 2644 UIKit 0x30a66110 -[UIApplication sendEvent:] + 2485 UIKit 0x30a6565c _UIApplicationHandleEvent + 40886 GraphicsServices 0x3169b0b4 PurpleEventCallback + 4287 GraphicsServices 0x3169d818 HeartbeatVBLCallback + 1528 IOMobileFramebuffer 0x31f3e8f8 IOMobileFramebufferNotifyFunc + 1249 com.apple.framework.IOKit 0x30f342b8 IODispatchCalloutFromCFMessage + 30410 CoreFoundation 0x3025ced4 __CFMachPortPerform + 7211 CoreFoundation 0x3025bed6 CFRunLoopRunSpecific + 236412 CoreFoundation 0x3025b584 CFRunLoopRunInMode + 4413 GraphicsServices 0x316998e4 GSEventRunModal + 26814 UIKit 0x30a5e308 -[UIApplication _run] + 40415 UIKit 0x30a671dc UIApplicationMain + 106416 MobileLines 0x00002090 main (main.m:16)17 MobileLines 0x0000202c start + 44Now, this ismuch better. Happy debugging!
Other useful references:
gdb查看:
如果採用上述方法還是解析不出來，則可以利用gdb來解析：
方法如下：還是在.app,和.dSYM目錄下，
打開終端,輸入:
/Developer/Platforms/iPhoneOS.platform/Developer/usr/libexec/gdb/gdb-arm-apple-darwin 打包的.app/MyApp
要想顯示在哪個類，哪一行，則使用：
(gdb) set print symbol-filename on(gdb) p/a 0x0002b0ee
這裏0x0002b0ee 是你報錯程序的錯誤,如:
Thread 0 name: Dispatch queue: com.apple.main-thread
Thread 0 Crashed:
0 libobjc.A.dylib 0x34bc8c9a objc_msgSend + 18
1 UIKit 0x34309146 -[UIViewController didReceiveMemoryWarning] + 10
2 UIKit 0x3430915c -[UIViewController _didReceiveMemoryWarning:] + 8
3 Foundation 0x36b7d17c _nsnote_callback + 136
4 CoreFoundation 0x355bb208 __CFXNotificationPost_old + 396
5 CoreFoundation 0x35555ee4 _CFXNotificationPostNotification + 112
6 Foundation 0x36b7a5cc -[NSNotificationCenter postNotificationName:object:userInfo:] + 64
7 Foundation 0x36b7c1ba -[NSNotificationCenter postNotificationName:object:] + 18
8 UIKit 0x342df35a -[UIApplication _performMemoryWarning] + 42
9 UIKit 0x342dfd7c -[UIApplication _receivedMemoryNotification] + 120
10 UIKit 0x342dd500 _memoryStatusChanged + 36
11 CoreFoundation 0x355bbd62 __CFNotificationCenterDarwinCallBack + 18
12 CoreFoundation 0x355b8bd8 __CFMachPortPerform + 204
13 CoreFoundation 0x355c3a90 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE1_PERFORM_FUNCTION__ + 20
14 CoreFoundation 0x355c5838 __CFRunLoopDoSource1 + 160
15 CoreFoundation 0x355c6606 __CFRunLoopRun + 514
16 CoreFoundation 0x35556ebc CFRunLoopRunSpecific + 224
17 CoreFoundation 0x35556dc4 CFRunLoopRunInMode + 52
18 GraphicsServices 0x3417d418 GSEventRunModal + 108
19 GraphicsServices 0x3417d4c4 GSEventRun + 56
20 UIKit 0x341b4d62 -[UIApplication _run] + 398
21 UIKit 0x341b2800 UIApplicationMain + 664
22 PABankiPad 0x00002618 0x1000 + 5656
23 PABankiPad 0x000025cc 0x1000 + 5580
這裏,可以用:p/a 0x00002618
查看.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
對比結果是否一致.
把命令鏈接到所有用戶可以使用
sudo ln -s /Developer/Platforms/iPhoneOS.platform/Developer/Library/PrivateFrameworks/DTDeviceKit.framework/Versions/A/Resources/symbolicatecrash /usr/local/bin/
sudo ln -s /Developer/Platforms/iPhoneOS.platform/Developer/usr/libexec/gdb/gdb-arm-apple-darwin/usr/local/bin/
批量轉換日誌:(app包和dSYM還有carsh文件都放到對應的目錄下了)
cd ~/Desktop/a1201s4z1.5c
pwd
k=1
for i in *.crash;do
echo $i
symbolicatecrash $i PABankiPad.app.dSYM > $k.log
((k++))
done