iOS Crash Report - how to find crashing place

Question

lastly I uploaded app to appstore. I am using also Flurry analytics, and few errors were captured there.

I tried to attach dSYM file to make it more readable, however I am not sure which part of such log changes into human readable text.

Other thing here: I don't see any line that points to one of my class files (implemenation).

So my questions are - How can I get some more information from such report? - Is is true, that the app really crashed on user device? Or maybe such error was invisible for a user? - Is it possible that the app didn't crash but maybe user killed its process?

Thanks

Here is the crash report

Hardware Model:      iPhone3,3
Process:         my-app [560]
Path:            /var/mobile/Applications/3539397F-14A1-4802-A388-1D5070404D98/my id
Identifier:      /my id
Version:         1.3
Code Type:       ARM
Parent Process:  launchd [1]

Exception Type:  SIGSEGV
Exception Codes: SEGV_ACCERR at 0x70000008
Crashed Thread:  0

Thread 0 Crashed:
0   libobjc.A.dylib                     0x34dde5b0 +[Protocol load] + 663
1   UIKit                               0x3471b4a7 0x34699000 + 533671
2   UIKit                               0x346b1abb 0x34699000 + 101051
3   UIKit                               0x347268d7 0x34699000 + 579799
4   QuartzCore                          0x34cdabd9 -[CALayer dealloc] + 1244
5   libdispatch.dylib                   0x3793d4b7 0x3793c000 + 5303
6   libdispatch.dylib                   0x3793edcb -[OS_object release] + 274
7   CoreFoundation                      0x3826af3b +[__NSCFLocale         automaticallyNotifiesObserversForKey:] + 12398
8   CoreFoundation                      0x381ddebd -[__NSDate timeIntervalSinceReferenceDate] + 500
9   CoreFoundation                      0x381ddd49 -[__NSDate timeIntervalSinceReferenceDate] + 128
10  GraphicsServices                    0x3887a2eb 0x38875000 + 21227
11  UIKit                               0x346f0301 0x34699000 + 357121
12  my-app                              0x0012987b -[ASIHTTPRequest setSynchronous:] + 86

Thread 1:
0   libsystem_kernel.dylib              0x3568c648 0x3568b000 + 5704
1   libdispatch.dylib                   0x3793fdf8 -[OS_object _dispose] + 579

Thread 2:
0   libsystem_kernel.dylib              0x3568beb4 0x3568b000 + 3764
1   CoreFoundation                      0x3826c045 +[__NSCFLocale     automaticallyNotifiesObserversForKey:] + 16760
2   CoreFoundation                      0x3826ada3 +[__NSCFLocale  automaticallyNotifiesObserversForKey:] + 11990
3   CoreFoundation                      0x381ddebd -[__NSDate timeIntervalSinceReferenceDate] + 500
4   CoreFoundation                      0x381ddd49 -[__NSDate timeIntervalSinceReferenceDate] + 128
5   WebCore                             0x3689ca75 +[WebScriptObject initialize] + 608
6   libsystem_c.dylib                   0x364f5311 0x364e4000 + 70417

Thread 3:
0   libsystem_kernel.dylib              0x3568beb4 0x3568b000 + 3764
1   CoreFoundation                      0x3826c045 +[__NSCFLocale automaticallyNotifiesObserversForKey:] + 16760
2   CoreFoundation                      0x3826ada3 +[__NSCFLocale automaticallyNotifiesObserversForKey:] + 11990
3   CoreFoundation                      0x381ddebd -[__NSDate timeIntervalSinceReferenceDate] + 500
4   CoreFoundation                      0x381ddd49 -[__NSDate timeIntervalSinceReferenceDate] + 128
5   Foundation                          0x3264cbcd +[NSURLConnection _resourceLoadLoop:] + 308
6   Foundation                          0x326d067d -[NSThread description] + 1096
7   libsystem_c.dylib                   0x364f5311 0x364e4000 + 70417

Thread 4:
0   libsystem_kernel.dylib              0x3568beb4 0x3568b000 + 3764
1   CoreFoundation                      0x3826c045 +[__NSCFLocale  automaticallyNotifiesObserversForKey:] + 16760
2   CoreFoundation                      0x3826ada3 +[__NSCFLocale automaticallyNotifiesObserversForKey:] + 11990
3   CoreFoundation                      0x381ddebd -[__NSDate timeIntervalSinceReferenceDate] + 500
4   CoreFoundation                      0x381ddd49 -[__NSDate timeIntervalSinceReferenceDate] + 128
5   my-app                           0x001275eb +[ASIHTTPRequest runRequests] + 170
6   Foundation                          0x326d067d -[NSThread description] + 1096
7   libsystem_c.dylib                   0x364f5311 0x364e4000 + 70417

Thread 5:
0   libsystem_kernel.dylib              0x3569c594 0x3568b000 + 71060
1   libsystem_c.dylib                   0x364f5311 0x364e4000 + 70417

Thread 6:
0   libsystem_kernel.dylib              0x3568beb4 0x3568b000 + 3764
1   CoreFoundation                      0x3826c045 +[__NSCFLocale   automaticallyNotifiesObserversForKey:] + 16760
2   CoreFoundation                      0x3826ada3 +[__NSCFLocale automaticallyNotifiesObserversForKey:] + 11990
3   CoreFoundation                      0x381ddebd -[__NSDate timeIntervalSinceReferenceDate] + 500
4   CoreFoundation                      0x381ddd49 -[__NSDate timeIntervalSinceReferenceDate] + 128
5   Foundation                          0x3262378f +[NSNotification allocWithZone:] + 334
6   Foundation                          0x326c705d +[NSPropertyListSerialization propertyListWithStream:options:format:error:] + 9132
7   my-app                              0x0013a9ad +[TFURLConnectionOperation _runNetworkThread:] + 140
8   Foundation                          0x326d067d -[NSThread description] + 1096
9   libsystem_c.dylib                   0x364f5311 0x364e4000 + 70417

Thread 7:
0   libsystem_kernel.dylib              0x3569cd98 0x3568b000 + 73112
1   libsystem_c.dylib                   0x364eaa16 0x364e4000 + 27158

Thread 8:
0   libsystem_kernel.dylib              0x3569cd98 0x3568b000 + 73112
1   libsystem_c.dylib                   0x364eaa16 0x364e4000 + 27158

Thread 0 crashed with ARM Thread State:
r0: 0x1fc42250     r1: 0x34b1bee8     r2: 0x2fdf0d60     r3: 0x348a80d5 
r4: 0x70000000     r5: 0x1fc42250     r6: 0x1fc42360     r7: 0x2fdf0e3c 
r8: 0x1ed3c720     r9: 0x0d2c6fba    r10: 0x1fc1b290    r11: 0x00000001 
ip: 0x3b9a7d64     sp: 0x2fdf0db4     lr: 0x3471b84b     pc: 0x34dde5b0 
cpsr: 0x20000030 

Answer 1

Regarding your questions:

Question 1: How can I get some more information from such report?

Answer:

1. The signal is SIGSEGV which basically means a segmentation fault. There are several possible reasons for such a crash, e.g. a overreleased object, an non initialised pointer or code that writes directly into memory.
2. The crashing thread shows a dealloc call in the stack trace. This is hinting the crash was caused while an object was deallocated.
3. Lots of background threads are running a network operation with ASIHTTPRequest with similar calls in the stack traces.
4. There are a lot of mentions of automaticallyNotifiesObserversForKey which hints that Key-Value-Observing is involved. Maybe there is an observer registered to a key, and the observer is already deallocated. It is even more tricky, since the notifications are triggered from a background thread! E.g. doing networking in the background and observing with an object on the main thread. It is pretty easy to get such crashes in these scenarios if you don't make sure the object on the main thread lives long enough.
5. It is really really really strange that multiple background threads have nearly identical stack traces with even identical memory addresses for individual stack frames.

Assumption: If you can't reproduce this problem you might not find the cause. I suspect it is somehow related to ASIHTTPRequest and either its internal key-value-coding handling or your own use of that. So I would replace that library e.g. with AFNetworking or using the plain networking stack provided by iOS. In addition if you are using key-value-coding, check the code regarding multi-threading safety.

Question 2: Is is true, that the app really crashed on user device?

Yes, you get these reports only on real app crashes.

Question 3: Or maybe such error was invisible for a user?

No, SIGSEGV is a real crash of your app. Invisible would be, if you catch an exception in your code and still generate a report and send it over. But as far as I know Flurry doesn't provide this feature, you obviously didn't implement it and that crash is not caused by an exception either. So this is impossible.

Question 4: Is it possible that the app didn't crash but maybe user killed its process?

If apps get killed, you won't get a crash report by Flurry. Kills are triggered by iOS and in-process-crash reporting libraries (which means every 3rd party crash reporting service) can never ever create a report for these.

Additional note: Exception breakpoints (as others suggested) don't help on this type of crash, since it did not crash because an exception occured.

Answer 2

may be ask directly at flurry - crashanalytics@flurry.com ? I hope they can better help you with it.

take a look at your places there you do internet requests - I think it's something in this place.

For better testing I think you need to find iPhone3.3 version (as I know it's verizon iphone 4) and try to debug your app directly on this device.