I receive crash reports which are quite obscure. What is the strategy with stack traces such as the following.
Thread 7 crashed
0 libobjc.A.dylib objc_msgSend + 9
1 Foundation -[NSOperation release] + 148
2 Foundation __release_object_op + 22
3 libdispatch.dylib _dispatch_async_f_redirect_invoke + 82
4 libdispatch.dylib _dispatch_worker_thread2 + 262
5 libsystem_c.dylib _pthread_wqthread + 294
I have been looking at the different threads to see if one of them could point at some specific part of my app but all the threads are waiting in some system libraries or in the main loop.
Any hint?
Bruno
Related
My application crashed again, this time exporting the device crash log as follows (mind articles 11 and 12):
I tried to symbolic it, but I didn't know how to get the dSYM files from afnetworking from the project.
Thread 8 name: Dispatch queue: NSOperationQueue 0x2803df960 (QOS: UNSPECIFIED)
Thread 8 Crashed:
0 libsystem_malloc.dylib 0x0000000197cccda8 nanov2_allocate_from_block$VARIANT$armv81 + 528
1 libsystem_malloc.dylib 0x0000000197cccda8 nanov2_allocate_from_block$VARIANT$armv81 + 528
2 libsystem_malloc.dylib 0x0000000197ccc040 nanov2_allocate$VARIANT$armv81 + 140
3 libsystem_malloc.dylib 0x0000000197ccbf64 nanov2_malloc$VARIANT$armv81 + 60
4 libsystem_malloc.dylib 0x0000000197cd99a0 malloc_zone_malloc + 156
5 CoreFoundation 0x000000019808e160 _CFRuntimeCreateInstance + 324
6 CoreFoundation 0x000000019802b970 __CFArrayInit + 224
7 Foundation 0x0000000198b75470 NSKVOCopyPendingNotificationStack + 152
8 Foundation 0x0000000198b720f8 NSKeyValueWillChangeWithPerThreadPendingNotifications.llvm.16432713543580414412 + 364
9 Foundation 0x0000000198ae8ad4 -[NSProgress _setValueForKeys:settingBlock:] + 272
10 Foundation 0x0000000198aeb9dc -[NSProgress setCompletedUnitCount:] + 132
11 AFNetworking 0x00000001051c965c 0x10519c000 + 185948
12 AFNetworking 0x00000001051d1a18 0x10519c000 + 219672
13 CFNetwork 0x0000000198898b94 __67-[NSURLSession delegate_dataTask:didReceiveData:completionHandler:]_block_invoke.303 + 36
14 Foundation 0x0000000198b8c8bc __NSBLOCKOPERATION_IS_CALLING_OUT_TO_A_BLOCK__ + 16
15 Foundation 0x0000000198a94ab8 -[NSBlockOperation main] + 72
16 Foundation 0x0000000198a93f8c -[__NSOperationInternal _start:] + 740
17 Foundation 0x0000000198b8e790 __NSOQSchedule_f + 272
18 libdispatch.dylib 0x0000000197b356c8 _dispatch_call_block_and_release + 24
19 libdispatch.dylib 0x0000000197b36484 _dispatch_client_callout + 16
20 libdispatch.dylib 0x0000000197b0ce04 _dispatch_continuation_pop$VARIANT$armv81 + 404
21 libdispatch.dylib 0x0000000197b0c4e8 _dispatch_async_redirect_invoke + 592
22 libdispatch.dylib 0x0000000197b18aec _dispatch_root_queue_drain + 344
23 libdispatch.dylib 0x0000000197b1934c _dispatch_worker_thread2 + 116
24 libsystem_pthread.dylib 0x0000000197d1917c _pthread_wqthread + 472
25 libsystem_pthread.dylib 0x0000000197d1bcec start_wqthread + 4
If it's not afnetworking fault, can anyone see why? Please help me.
So, your app has crashed pretty deep in Apple's code, and specifically inside libsystem_malloc. While I cannot be certain, my guess is you're looking at an example of heap corruption.
Dynamically allocated memory is shared by your entire process, and everything in it. That means that any code could potentially overwrite and/or otherwise corrupt structures used by other, even unrelated, parts of the system. In this case, it looks like something has messed up the internal book-keeping structures used by malloc. I would guess this happens by overrunning a buffer and writing outside of an allocated piece of memory's bounds.
What I can say with high confidence is that this particular report does not give you enough information to blame AFNetworking. It just happened to be unlucky enough to be running when that corrupt memory was accessed. Even one memory corruption bug can cause a variety of different crashes. Because of that, it's not really possible to reason about the cause of any one particular crash.
The good news is this kind of thing is very common. Bad news is it can be very hard to track down. What I'd recommend trying is to make use of the memory debugging tools that Apple provides. Things like NSZombies (via instruments), guardmalloc, and malloc scribble. Your best bet is to just fix all the memory-related bugs you can find.
In my iOS app, I keep getting crash reports like this one.
0 libsystem_kernel.dylib 0x000000018d805014 __pthread_kill + 4
1 libsystem_c.dylib 0x000000018d7799c4 abort + 136
2 libc++abi.dylib 0x000000018d2451b0 abort_message + 128
3 libc++abi.dylib 0x000000018d25ec04 default_terminate_handler() + 300
4 libobjc.A.dylib 0x000000018d26c820 objc_terminate() + 120
5 libc++abi.dylib 0x000000018d25b5d4 std::__terminate() + 12
6 libc++abi.dylib 0x000000018d25b640 std::terminate() + 56
7 libdispatch.dylib 0x000000018d6c29b4 _dispatch_client_callout + 32
8 libdispatch.dylib 0x000000018d6c75e8 _dispatch_main_queue_callback_4CF + 992
9 CoreFoundation 0x000000018e7b90c0 __CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__ + 8
10 CoreFoundation 0x000000018e7b6cdc __CFRunLoopRun + 1568
11 CoreFoundation 0x000000018e6e6d94 CFRunLoopRunSpecific + 420
12 GraphicsServices 0x0000000190150074 GSEventRunModal + 96
13 UIKit 0x000000019499f44c UIApplicationMain + 204
! 14 MyAppNameHere 0x000000010007b090 main (main.m:33)
15 libdyld.dylib 0x000000018d6f559c start + 0
The strange thing is that none of this exists within my code except for the main.m. All other threads in my application don't have anything related to either. This crash appears to only happen for a fraction of a percent of my users, so I am not sure where to even start looking.
The question as it is formulated right now is not answerable, because it is missing necessary information. See e.g. this tutorial for an explanation of how to obtain a real backtrace and how to obtain a "crash reason". Without following the recommended steps for debugging crashes every crash of an iOS-app looks exactly the same as the crash you just provided.
In order to get a real/useful backtrace, you need to set an exception breakpoint in Xcode.
I've got an odd crash I'm trying to debug, and some help would be most appreciated.
My main thread crashes like so:
Thread : Crashed: com.apple.main-thread
0 libsystem_kernel.dylib 0x3316ddfc __pthread_kill + 8
1 libsystem_pthread.dylib 0x331ebd37 pthread_kill + 62
2 libsystem_c.dylib 0x3310d909 abort + 76
3 libc++abi.dylib 0x324389c9 __cxa_bad_cast
4 libc++abi.dylib 0x3244fe29 std::__terminate(void (*)()) + 148
5 libc++abi.dylib 0x3244f8af __cxa_rethrow + 102
6 libobjc.A.dylib 0x32b27dd3 objc_exception_rethrow + 42
7 CoreFoundation 0x2522245d CFRunLoopRunSpecific + 632
8 CoreFoundation 0x252221d3 CFRunLoopRunInMode + 106
9 GraphicsServices 0x2c5da0a9 GSEventRunModal + 136
10 UIKit 0x28831fa1 UIApplicationMain + 1440
11 LifeLock Wallet 0x000e98b1 main (main.mm:21)
The other threads looked alright, until I saw this background thread, where I'm generating 2048-bit RSA keys:
Thread : RSA Key Gen Queue
0 libsystem_kernel.dylib 0x3315c064 fsync + 8
1 MyApp 0x00c697f5 unixSync (sqlite3.c:30624)
2 MyApp 0x00c310f5 syncJournal (sqlite3.c:19113)
3 MyApp 0x00c10d47 sqlite3PagerCommitPhaseOne (sqlite3.c:49218)
4 MyApp 0x00c1101d sqlite3BtreeCommitPhaseOne (sqlite3.c:56943)
5 MyApp 0x00c63107 sqlite3VdbeHalt (sqlite3.c:66150)
6 MyApp 0x00c62bd1 sqlite3VdbeExec (sqlite3.c:70841)
7 MyApp 0x00c11f33 sqlite3_step (sqlite3.c:68643)
8 MyApp 0x00c0cfdf sqlite3_exec (sqlite3.c:98380)
9 MyApp 0x000ee3eb +[DBHelper execStringNormal:] (DBHelper.m:88)
10 MyApp 0x000f448b +[DBHelper insertCategories] (DBHelper.m:1373)
11 MyApp 0x000f34ed +[DBHelper createDB] (DBHelper.m:1147)
12 MyApp 0x000ee97b +[DBHelper initSqlite] (DBHelper.m:212)
13 MyApp 0x000ea245 -[MyApp databaseSetup (MyAppDelegate.m:187)
14 MyApp 0x001fcc69 __37-[Security generateRSAKeyPair]_block_invoke (Security.m:317)
15 libdispatch.dylib 0x330877bb _dispatch_call_block_and_release + 10
16 libdispatch.dylib 0x3308f5b1 _dispatch_queue_drain + 952
17 libdispatch.dylib 0x33089f85 _dispatch_queue_invoke + 84
18 libdispatch.dylib 0x33090b9b _dispatch_root_queue_drain + 338
19 libdispatch.dylib 0x33091cd7 _dispatch_worker_thread3 + 94
20 libsystem_pthread.dylib 0x331e8e31 _pthread_wqthread + 668
This caught my eye because of the general flow in my code. In a nutshell:
A GCD background thread is created on app start, to generate my RSA keys.
The class that creates the RSA keys has a protocol to call back to a delegate (in this case, my app delegate), when the keys are ready.
On the same GCD background thread, I call back to my delegate object.
Once my app delegate gets called back, I open my SQLite connection and write to the local DB.
My questions are:
Would writing to the SQLite DB on a background thread cause my 'pthread_kill' crash?
Is it worth serializing my SQLite DB to ensure that, in the event I have other threads writing to SQLite, I stay thread-safe?
Thanks!
This is the crash report I received from crashlytics and I don't have the slightest clue on what it means or what to do about this. Any tips or suggestions will be appreciated.
Thread : Crashed: NSOperationQueue Serial Queue
0 libsystem_platform.dylib 0x3baef4da _platform_memmove$VARIANT$Swift + 185
1 ??? 0x0000000c
2 DataDetectorsCore 0x350b26bb DDTokenCacheGetItemAtIndexCreateIfNeeded + 90
3 DataDetectorsCore 0x350b2635 DDTokenCacheGetTokensAtPosition + 1084
4 DataDetectorsCore 0x350ae41d _DDScannerHandleState + 472
5 DataDetectorsCore 0x350aea71 _DDScannerHandleState + 2092
6 DataDetectorsCore 0x350addf1 DDScannerScanQuery + 328
7 DataDetectorsUI 0x350c8f7d -[DDOperation main] + 288
8 Foundation 0x31664aa5 -[__NSOperationInternal _start:] + 772
9 Foundation 0x3170896d __NSOQSchedule_f + 60
10 libdispatch.dylib 0x3b9c5e7b _dispatch_queue_drain + 374
11 libdispatch.dylib 0x3b9c2f93 _dispatch_queue_invoke + 42
12 libdispatch.dylib 0x3b9c6745 _dispatch_root_queue_drain + 76
13 libdispatch.dylib 0x3b9c69c5 _dispatch_worker_thread2 + 56
14 libsystem_pthread.dylib 0x3baf0dff _pthread_wqthread + 298
Do you have any part of your app where the user clicks on a URL or specifies a URL which is then handled by your app, or by the system on behalf of your app. The subsystem that does this is DataDetectorsCore.
If you have code around that area, it would be a good idea to add log messages, assert checks, validation, and unit test code.
It might be that you are receiving maliciously crafted URLs; here is an example but for the Mac platform: http://nakedsecurity.sophos.com/2013/02/06/anatomy-of-a-bug-how-mac-os-x-chokes-if-you-type-file/
In one of our iPhone apps, we have gotten a few Crashlytics crashes that we have, so far, been unable to reproduce. However, on closer inspection, I noticed a bit of a trend...
Crash 1: -[UINavigationTransitionView _notifyDelegateTransitionDidStopWithContext:]
Free RAM: 10%
Crash 2: -[UINavigationTransitionView _notifyDelegateTransitionDidStopWithContext:]
Free RAM: 8%
Crash 3: HostBase::lock()
Free RAM: 8%
Crash 4:-[UINavigationTransitionView _notifyDelegateTransitionDidStopWithContext:]
Free RAM: 22%
Does the amount of free RAM mean anything? Can we be sure that these are actual crashes and not our app getting killed by the OS due to low memory? Does Crashlytics send crash reports if the app crashes while in the background?
Added a couple stack traces...
Exception Type: SIGSEGV, Nav Crashes
0 libobjc.A.dylib
objc_msgSend + 15
1 UIKit ✭
-[UINavigationTransitionView _notifyDelegateTransitionDidStopWithContext:] + 274
2 UIKit
-[UIViewAnimationState sendDelegateAnimationDidStop:finished:] + 158
3 UIKit
-[UIViewAnimationState animationDidStop:finished:] + 50
4 QuartzCore
CA::Layer::run_animation_callbacks(void*) + 208
5 libdispatch.dylib
_dispatch_client_callout + 22
6 libdispatch.dylib
_dispatch_main_queue_callback_4CF$VARIANT$mp + 224
7 CoreFoundation
__CFRunLoopRun + 1290
8 CoreFoundation
CFRunLoopRunSpecific + 356
9 CoreFoundation
CFRunLoopRunInMode + 104
10 GraphicsServices
GSEventRunModal + 74
11 UIKit
UIApplicationMain + 1120
Exception Type: SIGSEGV, HostLock crash
0 libobjc.A.dylib
objc_msgSend + 15
1 CFNetwork ✭
HostBase::lock() + 14
2 CFNetwork
DispatchHost::performInvocation(void const*) + 12
3 CFNetwork
__setupTCPConnection_block_invoke_2 + 290
4
...
libsystem_network.dylib
__tcp_connection_notify_complete_block_invoke_1 + 18
7 libsystem_c.dylib
_pthread_wqthread + 294
8% memory can be a lot, I highly doubt that this is an issue. I don't know if they send crashes while running in the background, you have to ask them directly since their SDK is not open source.
Both exception stack traces you added hint at a memory problem.
The first one looks like it tries to call a delegate at the end of an animation of an object, which does not exist any more.
The second one looks like a similar problem, where the completion block is accessing an object that is gone. So you might check your blocks for such patterns.