在我当前的项目中,我得到随机崩溃,可能是由于内存过冲。但我实际上想弄清楚哪个类导致崩溃。所以我使用符号方法来查找崩溃的原因。 这就是我所做的:
首先,XCode Build设置如下:
复制期间剥离调试Sysbols:否 部署后处理:是 剥离链接产品:是 生成调试符号:是 调试信息格式:带有dSYM文件的DWARF 使用单独的条带:是
我正在使用iOS 5.1和4.3.2版本的XCode。我使用了“symbolicatecrash”和“atos”方法来揭示崩溃的原因。但是我无法找到崩溃的原因。
所以我尝试了这个。我通过访问数组中的out of bound索引使应用程序崩溃。我用它来验证符号化的崩溃结果输出与我的实际崩溃。
以下是崩溃报告输出:
Incident Identifier: 93678EE5-ED10-4502-A59B-5C7526640C4D
CrashReporter Key: 5a79e41767bd1988a9b4080ee5641f63ed42feb8
Hardware Model: iPad2,1
Process: MyAppName [887]
Path: /var/mobile/Applications/EF2C944B-4C26-4EB6-B41E-F89CF2232ADB/JAYPORE.app/MyAppName
Identifier: MyAppName
Version: ??? (???)
Code Type: ARM (Native)
Parent Process: launchd [1]
Date/Time: 2012-07-13 13:37:18.642 +0530
OS Version: iPhone OS 5.0.1 (9A405)
Report Version: 104
Exception Type: EXC_CRASH (SIGABRT)
Exception Codes: 0x00000000, 0x00000000
Crashed Thread: 0
Thread 0 name: Dispatch queue: com.apple.main-thread
Thread 0 Crashed:
0 libsystem_kernel.dylib 0x3028432c __pthread_kill + 8
1 libsystem_c.dylib 0x37725f54 pthread_kill + 48
2 libsystem_c.dylib 0x3771efe4 abort + 88
3 MyAppName 0x00104aa0 0x5e000 + 682656
4 Foundation 0x34ebc1b0 -[NSObject(NSThreadPerformAdditions) performSelector:onThread:withObject:waitUntilDone:modes:] + 260
5 Foundation 0x34ebbe42 -[NSObject(NSThreadPerformAdditions) performSelectorOnMainThread:withObject:waitUntilDone:] + 130
6 MyAppName 0x00104924 0x5e000 + 682276
7 MyAppName 0x00118634 0x5e000 + 763444
8 MyAppName 0x00116b36 0x5e000 + 756534
9 libsystem_c.dylib 0x37730532 _sigtramp + 42
10 libsystem_c.dylib 0x37725f54 pthread_kill + 48
11 libsystem_c.dylib 0x3771efe4 abort + 88
12 MyAppName 0x00118658 0x5e000 + 763480
13 CoreFoundation 0x37c23980 __handleUncaughtException + 68
14 libobjc.A.dylib 0x3776f2ca _objc_terminate + 122
15 libc++abi.dylib 0x3017e3be _ZL19safe_handler_callerPFvvE + 70
16 libc++abi.dylib 0x3017e44a std::terminate() + 14
17 libc++abi.dylib 0x3017f81e __cxa_rethrow + 82
18 libobjc.A.dylib 0x3776f22e objc_exception_rethrow + 6
19 CoreFoundation 0x37b7953e CFRunLoopRunSpecific + 398
20 CoreFoundation 0x37b7939e CFRunLoopRunInMode + 98
21 GraphicsServices 0x37950fc6 GSEventRunModal + 150
22 UIKit 0x316f973c UIApplicationMain + 1084
23 MyAppName 0x0005ffc8 0x5e000 + 8136
24 MyAppName 0x0005ff6c 0x5e000 + 8044
Thread 1 name: Dispatch queue: com.apple.libdispatch-manager
Thread 1:
0 libsystem_kernel.dylib 0x302743b4 kevent + 24
1 libdispatch.dylib 0x307dff74 _dispatch_mgr_invoke + 708
2 libdispatch.dylib 0x307dfc92 _dispatch_mgr_thread + 30
Thread 2 name: WebThread
Thread 2:
0 libsystem_kernel.dylib 0x30274010 mach_msg_trap + 20
1 libsystem_kernel.dylib 0x30274206 mach_msg + 50
2 CoreFoundation 0x37bf741c __CFRunLoopServiceMachPort + 120
3 CoreFoundation 0x37bf6154 __CFRunLoopRun + 876
4 CoreFoundation 0x37b794d6 CFRunLoopRunSpecific + 294
5 CoreFoundation 0x37b7939e CFRunLoopRunInMode + 98
6 WebCore 0x32650128 _ZL12RunWebThreadPv + 396
7 libsystem_c.dylib 0x376e7c16 _pthread_start + 314
8 libsystem_c.dylib 0x376e7ad0 thread_start + 0
Thread 3 name: com.apple.NSURLConnectionLoader
Thread 3:
0 libsystem_kernel.dylib 0x30274010 mach_msg_trap + 20
1 libsystem_kernel.dylib 0x30274206 mach_msg + 50
2 CoreFoundation 0x37bf741c __CFRunLoopServiceMachPort + 120
3 CoreFoundation 0x37bf6154 __CFRunLoopRun + 876
4 CoreFoundation 0x37b794d6 CFRunLoopRunSpecific + 294
5 CoreFoundation 0x37b7939e CFRunLoopRunInMode + 98
6 Foundation 0x34ec8bc2 +[NSURLConnection(Loader) _resourceLoadLoop:] + 302
7 Foundation 0x34ec8a8a -[NSThread main] + 66
8 Foundation 0x34f5c59a __NSThread__main__ + 1042
9 libsystem_c.dylib 0x376e7c16 _pthread_start + 314
10 libsystem_c.dylib 0x376e7ad0 thread_start + 0
Thread 4 name: com.apple.CFSocket.private
Thread 4:
0 libsystem_kernel.dylib 0x30284570 __select + 20
1 CoreFoundation 0x37bfb66a __CFSocketManager + 726
2 libsystem_c.dylib 0x376e7c16 _pthread_start + 314
3 libsystem_c.dylib 0x376e7ad0 thread_start + 0
Thread 5 name: Dispatch queue: com.apple.CFURLCACHE_work_queue
Thread 5:
0 libsystem_kernel.dylib 0x30275ac4 fsync + 8
1 libsqlite3.dylib 0x30741656 0x30704000 + 251478
2 libsqlite3.dylib 0x30746434 0x30704000 + 271412
3 libsqlite3.dylib 0x30741394 0x30704000 + 250772
4 libsqlite3.dylib 0x30737350 0x30704000 + 209744
5 libsqlite3.dylib 0x30719a6c 0x30704000 + 88684
6 libsqlite3.dylib 0x3072ccb4 0x30704000 + 167092
7 libsqlite3.dylib 0x3072b6ce sqlite3_step + 2098
8 libsqlite3.dylib 0x3070a732 sqlite3_exec + 366
9 CFNetwork 0x33a3cedc __CFURLCache::ExecSQLStatement_NoLock(sqlite3*, char const*, int (*)(void*, int, char**, char**), void*, long) + 32
10 CFNetwork 0x33a3fc7c _ZL24_CFURLCacheTimerCallbackPv + 320
11 libdispatch.dylib 0x307e133e _dispatch_source_invoke + 510
12 libdispatch.dylib 0x307dec60 _dispatch_queue_invoke$VARIANT$mp + 44
13 libdispatch.dylib 0x307ded9e _dispatch_queue_drain + 198
14 libdispatch.dylib 0x307dec56 _dispatch_queue_invoke$VARIANT$mp + 34
15 libdispatch.dylib 0x307df860 _dispatch_worker_thread2 + 204
16 libsystem_c.dylib 0x376e21c8 _pthread_wqthread + 288
17 libsystem_c.dylib 0x376e209c start_wqthread + 0
Thread 6:
0 libsystem_kernel.dylib 0x30284cd4 __workq_kernreturn + 8
1 libsystem_c.dylib 0x376e230a _pthread_wqthread + 610
2 libsystem_c.dylib 0x376e209c start_wqthread + 0
Thread 7:
0 libsystem_kernel.dylib 0x30284cd4 __workq_kernreturn + 8
1 libsystem_c.dylib 0x376e230a _pthread_wqthread + 610
2 libsystem_c.dylib 0x376e209c start_wqthread + 0
Thread 8:
0 libsystem_kernel.dylib 0x30274010 mach_msg_trap + 20
1 libsystem_kernel.dylib 0x30274206 mach_msg + 50
2 CoreFoundation 0x37bf741c __CFRunLoopServiceMachPort + 120
3 CoreFoundation 0x37bf6154 __CFRunLoopRun + 876
4 CoreFoundation 0x37b794d6 CFRunLoopRunSpecific + 294
5 CoreFoundation 0x37b7939e CFRunLoopRunInMode + 98
6 Foundation 0x34ebcb7e -[NSRunLoop(NSRunLoop) runMode:beforeDate:] + 250
7 Foundation 0x34ed652c -[NSRunLoop(NSRunLoop) run] + 72
8 JAYPORE 0x00108a9a 0x5e000 + 699034
9 Foundation 0x34ec8a8a -[NSThread main] + 66
10 Foundation 0x34f5c59a __NSThread__main__ + 1042
11 libsystem_c.dylib 0x376e7c16 _pthread_start + 314
12 libsystem_c.dylib 0x376e7ad0 thread_start + 0
Thread 9:
0 libsystem_kernel.dylib 0x30284cd4 __workq_kernreturn + 8
1 libsystem_c.dylib 0x376e230a _pthread_wqthread + 610
2 libsystem_c.dylib 0x376e209c start_wqthread + 0
Thread 10:
0 libsystem_kernel.dylib 0x30284cd4 __workq_kernreturn + 8
1 libsystem_c.dylib 0x376e230a _pthread_wqthread + 610
2 libsystem_c.dylib 0x376e209c start_wqthread + 0
Thread 11:
0 libsystem_kernel.dylib 0x30284cd4 __workq_kernreturn + 8
1 libsystem_c.dylib 0x376e230a _pthread_wqthread + 610
2 libsystem_c.dylib 0x376e209c start_wqthread + 0
Thread 0 crashed with ARM Thread State:
r0: 0x00000000 r1: 0x00000000 r2: 0x00000001 r3: 0x00000000
r4: 0x00000006 r5: 0x3f504ce8 r6: 0x30caec02 r7: 0x2fe5c4ec
r8: 0x00000006 r9: 0x00000000 r10: 0x00000005 r11: 0x2fe5c558
ip: 0x00000148 sp: 0x2fe5c4e0 lr: 0x37725f5b pc: 0x3028432c
cpsr: 0x00000010
Binary Images:
0x5e000 - 0x14efff +JAYPORE armv7 <a9b02230373d3b4aba282d21f94fb780> /var/mobile/Applications/EF2C944B-4C26-4EB6-B41E-F89CF2232ADB/JAYPORE.app/JAYPORE
0x1178000 - 0x1182fff AccessibilitySettingsLoader armv7 <45d7c264810c364b976dba254572d73d> /System/Library/AccessibilityBundles/AccessibilitySettingsLoader.bundle/AccessibilitySettingsLoader
0x2fe5d000 - 0x2fe7efff dyld armv7 <be7c0b491a943054ad12eb5060f1da06> /usr/lib/dyld
0x3001c000 - 0x30179fff libmecabra.dylib armv7 <170c82a3c716372abe7ae0aae96d4805> /usr/lib/libmecabra.dylib
......二进制图像的长列表。
现在当我使用“atos”从线程0(导致崩溃)获取崩溃的原因时
3 MyAppName 0x00104aa0 0x5e000 + 682656
使用上面的地址,它给了我这个输出:
MAC66:Resources sourabhbhardwaj$ atos -arch arm -o /Users/myPath/MyAppName.app.dSYM/Contents/Resources/DWARF/MyAppName 0x00079f6c 0x78000 + 8044
-[FirstViewController setUIAndText] (in MyAppName) (FirstViewController.m:85)
-[SecondViewController DeleteByID:] (in MyAppName) (SecondViewController.m:415)
+
-[MyController viewWillAppear:] (in MyAppName) (MyController.m:137)
这不是我所犯的实际崩溃线。我在其他视图控制器上崩溃了,输出完全不同。这怎么可能? 是的,我已经交叉检查我是否正在为该二进制文件使用完全相同的dSYM文件。
需要快速帮助。
由于 Sourabh
答案 0 :(得分:1)
我确信现在为时已晚,无法提供帮助,但以防万一:您可能无法提供所需的所有参数。特别是,请确保指定(使用-l)应用程序的加载地址,并使用-arch指定体系结构。您可以在上面引用的二进制图像行中找到它(它随每个故障转储而变化):
0x5e000 - 0x14efff +JAYPORE armv7 <a9b02230373d3b4aba282d21f94fb780> /var/mobile/Applications/EF2C944B-4C26-4EB6-B41E-F89CF2232ADB/JAYPORE.app/JAYPORE
0x5e000是加载地址。因此,请尝试运行类似xcrun atos -l 0x5e000 -arch armv7 -o YourArchive.xcarchive/Products/Applications/YourApp.app/YourApp 0x00104aa0
的内容。
您可以在Kerni's answer to this similar question中找到有关加载地址的详细信息以及每次更改的原因。 (但是虽然知道它是如何工作的很好,但通常使用-l参数来更自然而不是自己做数学。)
答案 1 :(得分:0)
在进行符号化之前,请确保您拥有与崩溃相同的.app
和.dSYM
版本,否则它将无法正确符号化。