symbolication with atos giving wrong reason for the crash - crash-reports

Question

In my current project I am getting random crashes,may be due to memory overshoot.But I actually want to figure out which class lead to that crash.So I used symbolication method to find the reason of crash.
Here is what I have done:
Firstly, XCode Build settings are like this :
Strip Debug Sysbols During Copy : NO
Deployment PostProcessing : YES
Strip Linked Product : YES
Generate Debug Symbols : YES
Debug Info Format : DWARF with dSYM file
Use Separate Strip : YES
I am using iOS 5.1 with 4.3.2 version of XCode. I have used "symbolicatecrash" and "atos" methods to reveal the reason of the crash.But I was not able to find the reason for the crash.
So I tried this. I made the application crash by myself by accessing an out of bound index from the array. I have used that to verify the symbolicated crash result output with my actual crash.
Here is the crash report output:
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
...long list of binary images.
Now when I use "atos" to get the reason of crash from the Thread 0(which caused the crash)
3 MyAppName 0x00104aa0 0x5e000 + 682656
using above address,it gives me this output:
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)
which is not the actual line of crash which I have made. I have made crash on other view controller and the output is entirely different.How can this be possible??
Yes,I have cross checked that I am using the exact same dSYM file for that binary.
Quick help needed.
Thanks
Sourabh

Answer 1

I'm sure this is too late to help, but just in case: you may not be giving atos all the parameters it needs. In particular, make sure you are specifying (with -l) the load address of the application, and (with -arch) the architecture. You can find this in the binary image line you quoted above (it changes with each crashdump):
0x5e000 - 0x14efff +JAYPORE armv7 <a9b02230373d3b4aba282d21f94fb780> /var/mobile/Applications/EF2C944B-4C26-4EB6-B41E-F89CF2232ADB/JAYPORE.app/JAYPORE
The 0x5e000 is the load address. So try running something like xcrun atos -l 0x5e000 -arch armv7 -o YourArchive.xcarchive/Products/Applications/YourApp.app/YourApp 0x00104aa0.
You can find more details about what the load address is and why it changes each time in Kerni's answer to this similar question. (But while it's good to know how it works, it's usually more convenient to use the -l parameter to atos rather than doing the math yourself.)

Answer 2

Before symbolicating, make sure you have the same .app and the .dSYM of the build that crashed or else it will not be symbolicated properly.