I'm trying to debug a crash for which I do not know the cause. Unfortunately, all I have is a stack trace I have retrieved from Crashlytics, and there is little evidence I can find of my app causing this to happen, so unfortunately I cannot provide any concrete code examples, I'm posting here for the sheer hope that someone has run into this before.
I'm seeing in all of the associated crash stack traces I've collected via Crashlytics that it's crashing on a thread titled "com.apple.avkit.seekQueue". The output looks as thus:
Crashed: com.apple.avkit.seekQueue
0 libobjc.A.dylib 0x18c3e17f4 objc_object::release() + 8
1 libsystem_blocks.dylib 0x18c86fa68 _Block_release + 160
2 libdispatch.dylib 0x18c81a9a0 _dispatch_client_callout + 16
3 libdispatch.dylib 0x18c828ad4 _dispatch_queue_serial_drain + 928
4 libdispatch.dylib 0x18c81e2cc _dispatch_queue_invoke + 884
5 libdispatch.dylib 0x18c828fa8 _dispatch_queue_override_invoke + 344
6 libdispatch.dylib 0x18c82aa50 _dispatch_root_queue_drain + 540
7 libdispatch.dylib 0x18c82a7d0 _dispatch_worker_thread3 + 124
8 libsystem_pthread.dylib 0x18ca23100 _pthread_wqthread + 1096
9 libsystem_pthread.dylib 0x18ca22cac start_wqthread + 4
The exception I see thanks to Crashlytics is EXC_BAD_ACCESS KERN_INVALID_ADDRESS 0x0000000000000020. From this I can only presume that there is an AVPlayer doing something to a deallocated or restricted memory address, but the stack trace doesn't reveal any other entry points into my app other than main.m in the main thread.
FWIW, Crashlytics also recommends the following:
The stack trace indicates that heap corruption may have caused your
app to crash. Memory corruption can occur pretty easily from freeing a
dangling pointer, a thread race, or bad pointer arithmetic. The
important thing to keep in mind is that the resulting crash may happen
long after the initial corruption. As a result, the stack trace for
this crash might not provide any clues to the location of the bug in
your code.
Having said all that, does anyone have any insight as to what might be causing this, how I can debug this, or even if it might be an issue with AVKit?
Related
Below I have given the crash log from crashlytics, no other information available.On checking the logs, the issue occurs at different scenarios each time. Could not replicate the issue. Could anyone help me out to analyse the issue in Apple tvos application.
Crashed: com.apple.main-thread
SIGTRAP 0x0000000....
0
InsightAgentTVOS
(Missing)
1
InsightAgentTVOS
(Missing)
2
InsightAgentTVOS
(Missing)
3
InsightAgentTVOS
(Missing)
4
InsightAgentTVOS
(Missing)
5
InsightAgentTVOS
(Missing)
3
libdispatch.dylib
_dispatch_call_block_and_release + 24
4
libdispatch.dylib
_dispatch_client_callout + 16
5
libdispatch.dylib
_dispatch_main_queue_callback_4CF + 872
6
CoreFoundation
__CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__ + 12
7
CoreFoundation
__CFRunLoopRun + 2480
8
CoreFoundation
CFRunLoopRunSpecific + 572
9
GraphicsServices
GSEventRunModal + 160
10
UIKitCore
-[UIApplication _run] + 1060
11
UIKitCore
UIApplicationMain + 164
The _dispatch_call_block_and_release is almost certainly not the issue (though it suggests that the underlying probably might be in some block that you dispatched with GCD). The SIGTRAP is suggests that the problem may be Swift runtime error, such as forced unwrapping/casting. For general overview of crash reports, refer to Analyzing a Crash Report.
FYI, the “(Missing)” might suggest that is this code was was not symbolicated or the wrong compilation options. When it’s built correctly, the crash reports show you the exact line number in one’s code. That eliminates the guesswork.
Above, I assumed that InsightAgentTVOS was your code. If not, as Rob Napier surmised, then the problem is undoubtedly in their library. Perhaps some required parameter was not supplied. (Forced unwrapping of some optional value is a common source of this sort of problem.) If you don’t find the issue, I’d suggest you open a ticket with them, providing a MCVE.
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.
I get this crash in my live app for my IAP. I'm stressed out by it since it's a missed revenue opportunity. Can anyone help me understand this crash report?
Crashed: com.apple.main-thread
EXC_BAD_ACCESS KERN_INVALID_ADDRESS 0x0000000000000010
raw
0
libobjc.A.dylib
objc_msgSend + 16
1
StoreKit
__34-[SKProductsRequest _handleReply:]_block_invoke + 52
2 libdispatch.dylib
_dispatch_call_block_and_release + 24
9 UIKit
UIApplicationMain + 204
10
MyApp
main.m line 14
main
11
libdispatch.dylib
(Missing)
Not much to go on there.
0 libobjc.A.dylib objc_msgSend + 16
1 StoreKit __34-[SKProductsRequest _handleReply:]_block_invoke + 52
If I were you I'd look carefully at your SKProductRequestDelegate's -productRequestDidReceiveResponse: method. Although it doesn't show up in the backtrace, sometimes they aren't 100% reliable.
The other thing to look for is to see if that delegate has somehow been released. Crashing in objc_msgSend is frequently due to that. Are you using ARC?
Here's an article that should be on every ObjC coder's reading list:
http://sealiesoftware.com/blog/archive/2008/09/22/objc_explain_So_you_crashed_in_objc_msgSend.html
Is this definitely a memory crash, or should I be looking for something else?
Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0x81093cd0
Crashed Thread: 0
Thread 0 name: Dispatch queue: com.apple.main-thread
Thread 0 Crashed:
0 libobjc.A.dylib 0x33563f78 objc_msgSend + 16
1 Foundation 0x34d6b92c __NSFireDelayedPerform + 408
2 CoreFoundation 0x35919a2c __CFRUNLOOP_IS_CALLING_OUT_TO_A_TIMER_CALLBACK_FUNCTION__ + 8
3 CoreFoundation 0x35919692 __CFRunLoopDoTimer + 358
4 CoreFoundation 0x35918268 __CFRunLoopRun + 1200
5 CoreFoundation 0x3589b49e CFRunLoopRunSpecific + 294
6 CoreFoundation 0x3589b366 CFRunLoopRunInMode + 98
7 GraphicsServices 0x33636432 GSEventRunModal + 130
8 UIKit 0x33073cce UIApplicationMain + 1074
Using the profiler, live bytes are well under 10MB at all times, and when memory warns happen I'm back to 3MB or below.
This statement returns YES, so I assume I have zombies enabled:
getenv("NSZombieEnabled") || getenv("NSAutoreleaseFreedObjectCheckEnabled")
When I'm running from Xcode, the app crashes without Xcode even being aware (after some arbitrary number of memory warns).
Any suggestions besides "run with NSZombies enabled?" And, is this definitely a memory crash?
SIGSEGV happens when the code tries to access memory that "doesn't exist" (that is, the address you are trying to use doesn't have a mapping in your virtual address space).
The exact cause of this can be a large number of things - the most common ones are:
Using pointers that are not (properly) initialized.
Walking off the end of an array.
Using memory that has been freed.
Note that all of the above are examples of "undefined behaviour", so you may well have situations where your code doesn't crash although it's doing something wrong, but the same code, under other circumstances, DOES go wrong.
Yes, this is a memory-related error (segmentation fault). Keep in mind that NSZombies can't catch every memory error.
My application is crashing when one of the views is purged from memory because of low-memory condition. At least this is what I understand from the crashlog. It happens on numerous screens but only when opening a Facebook dialog (using the Facebook SDK). Basically, looks like the system sometimes runs out of memory when we need to present a Facebook dialog (e.g. to let user post something on the Facebook timeline).
Date/Time: 2012-03-14 19:47:33.819 +0000
OS Version: iPhone OS 5.1 (9B176)
Report Version: 104
Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0x30000008
Crashed Thread: 0
Thread 0 name: Dispatch queue: com.apple.main-thread
Thread 0 Crashed:
0 libobjc.A.dylib 0x30f2bf78 objc_msgSend + 16
1 MyApp 0x00003c0e -LTBaseViewController viewDidUnload (LTBaseViewController.m:145)
2 MyApp 0x00004ea2 -LTBaseTableViewController viewDidUnload (LTBaseTableViewController.m:90)
3 UIKit 0x33766bd8 -[UIViewController unloadViewForced:] + 244
4 UIKit 0x338ae492 -[UIViewController purgeMemoryForReason:] + 58
5 Foundation 0x3071a4f8 __57-NSNotificationCenter addObserver:selector:name:object:_block_invoke_0 + 12
6 CoreFoundation 0x30e95540 ___CFXNotificationPost_block_invoke_0 + 64
7 CoreFoundation 0x30e21090 _CFXNotificationPost + 1400
8 Foundation 0x3068e3e4 -NSNotificationCenter postNotificationName:object:userInfo: + 60
9 Foundation 0x3068fc14 -NSNotificationCenter postNotificationName:object: + 24
10 UIKit 0x3387926a -UIApplication _performMemoryWarning + 74
11 UIKit 0x33879364 -UIApplication _receivedMemoryNotification + 168
12 libdispatch.dylib 0x36a12252 _dispatch_source_invoke + 510
13 libdispatch.dylib 0x36a0fb1e _dispatch_queue_invoke$VARIANT$up + 42
14 libdispatch.dylib 0x36a0fe64 _dispatch_main_queue_callback_4CF$VARIANT$up + 152
15 CoreFoundation 0x30e9c2a6 __CFRunLoopRun + 1262
16 CoreFoundation 0x30e1f49e CFRunLoopRunSpecific + 294
17 CoreFoundation 0x30e1f366 CFRunLoopRunInMode + 98
18 GraphicsServices 0x33fb6432 GSEventRunModal + 130
19 UIKit 0x336f5e76 UIApplicationMain + 1074
20 MyApp 0x00004818 main (main.m:16)
21 MyApp 0x000023b4 0x1000 + 5044
I checked and there are almost no memory leaks, e.g. when testing the app for an hour the total memory leaked was around 2-3Kb caused by some string-copying libraries. So I don't believe this is caused by the application. I guess that when the phone is not restarted for some time there are applications running in the background and when using Facebook SDK the memory becomes a problem and the system tries to recover the memory from random applications, including my application.
My question is, how can I prevent this crash from happening? How should I handle unloadViewForced on a view controller to make the app more robust in low-memory conditions? And lastly, am I right that this crashlog suggests the crash occurred because the system tried to free memory and my application didn't handle it properly?
Any help greatly appreciated.
What is most likely happening is that one of the objects being referred to and probably being released by LTBaseViewController viewDidUnload method is being doubly released. In fact, since the backtrace indicates that the crash is happing on line 145 of LTBaseViewController.m you should be able to quickly see which object is the culprit.