I have several production iOS apps that all use the Fabric framework for Crashlytics and Twitter integration. For the past few months I've been seeing a low-level crash show up in Crashlytics, but I have been unable to duplicate it.
Here is the stack trace and about all I have to go on:
Thread : Crashed: com.apple.main-thread
0 libobjc.A.dylib 0x0000000194eec174 objc_release + 20
1 libobjc.A.dylib 0x0000000194eed724 (anonymous namespace)::AutoreleasePoolPage::pop(void*) + 564
2 CoreFoundation 0x0000000183141074 _CFAutoreleasePoolPop + 28
3 Foundation 0x0000000184072588 -[NSAutoreleasePool release] + 148
4 UIKit 0x0000000187d443f4 -[UIApplication _run] + 588
5 UIKit 0x0000000187d3ef40 UIApplicationMain + 1488
6 GT CFPlus 0x000000010000e7ec main (main.m:16)
7 libdyld.dylib 0x000000019557ea08 start + 4
At that point I get an EXC_BAD_ACCESS KERN_INVALID_ADDRESS at 0x00000000e005bec8 message.
I've done the standard Googling of the problem and based on posts like this it seems obvious that I'm doing something that ARC doesn't like. I just can't figure out what that might be. I have tried turning on NSZombies and have also run my code against an Objective-C static analysis tool with no luck on either.
My question is: has anyone run into anything similar, especially when using the Fabric framework? If so, is this something that could be buried in the framework, or is it my own doing?
Related
I experiencing a crash in my app:
Thread 0 name:
Thread 0 Crashed:
0 LogoQuizAC 0x0000000104705218 __hidden#563_ + 0 (__hidden#957_:0)
1 LogoQuizAC 0x0000000104705218 _hidden#18_ + 592 (__hidden#957_:135)
2 LogoQuizAC 0x000000010470503c __hidden#564_ + 48 (__hidden#456_:0)
3 LogoQuizAC 0x000000010470503c _hidden#18_ + 116 (__hidden#957_:135)
4 LogoQuizAC 0x00000001046fcd6c _hidden#17_ + 504 (__hidden#454_:96)
5 LogoQuizAC 0x00000001046fcea0 _hidden#20_ + 36 (__hidden#456_:0)
6 Foundation 0x0000000182770b20 __NSFireTimer + 68 (NSTimer.m:270)
7 CoreFoundation 0x0000000181355fa0 __CFRUNLOOP_IS_CALLING_OUT_TO_A_TIMER_CALLBACK_FUNCTION__ + 32 (CFRunLoop.c:1807)
8 CoreFoundation 0x0000000181355ba0 __CFRunLoopDoTimer + 1064 (CFRunLoop.c:2415)
9 CoreFoundation 0x0000000181354ffc __CFRunLoopDoTimers + 328 (CFRunLoop.c:2575)
10 CoreFoundation 0x000000018134eee4 __CFRunLoopRun + 1936 (CFRunLoop.c:3090)
11 CoreFoundation 0x000000018134e21c CFRunLoopRunSpecific + 600 (CFRunLoop.c:3242)
12 GraphicsServices 0x0000000198f18784 GSEventRunModal + 164 (GSEvent.c:2259)
13 UIKitCore 0x0000000183d8eee8 -[UIApplication _run] + 1072 (UIApplication.m:3253)
14 UIKitCore 0x0000000183d9475c UIApplicationMain + 168 (UIApplication.m:4707)
15 LogoQuizAC 0x000000010453a404 main + 68 (RLockedCell.swift:21)
16 libdyld.dylib 0x000000018100e6b0 start + 4
I tried almost everything but can symbolicate the crash.
I tried using symbolicatecrash followed by these posts:
(_hidden#919_:0) inside crash symbolication file
Why aren't the crashlogs from Testflight symbolicating in Xcode?
Xcode Crash Organizer does Not Symbolicate .xccrashpoint Files
How to symbolicate crash log with Xcode 8?
how Symbolicate a crash file using xcarchive
How to symbolicate crash log Xcode?
But without any success.
What am I doing wrong? How can I figure out what causing the crash?
The good news that it is crashing in your code, not in Operating Systems or Library code, so you have a good chance to debug it. Your code that is crashing is running off a timer. Sometimes these bugs are seen because in testing, you are just testing the app. But in the real world, those timers fire when you are not expecting them.
For example, someone ran your app, then put it into the background when using another app, or for example they received a phone call whilst using the app. If you attach the full contents of the .crash file, it will give more information on the cause of the crash.
Another thing you can do is place asserts into your code, such as in your timer callback functions for each object you are relying on being non-null.
You may find that your app is trying to draw onto the screen but is in the background. This is a common reason for a crash seen in the field for games that use timers. That may sound like a generalisation but it is a suggestion to try and make you think differently about the real world environment your customers face which can the reason for the failure.
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
I'm running my ios app in ipad 1, the following crash happen sometime while app is running, i don't know where the crash happen. This mostly happen in ios 5.1.1 . Here the crash log,
Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0xf0000008
Crashed Thread: 0
Thread 0 name: Dispatch queue: com.apple.main-thread
Thread 0 Crashed:
0 libobjc.A.dylib 0x3387ef78 objc_msgSend + 16
1 UIKit 0x333ffa3a -[UIViewController unloadViewForced:] + 254
2 UIKit 0x335473a6 -[UIViewController purgeMemoryForReason:] + 58
3 Foundation 0x3507a4f8 __57-[NSNotificationCenter addObserver:selector:name:object:]_block_invoke_0 + 12
4 CoreFoundation 0x35c2c540 ___CFXNotificationPost_block_invoke_0 + 64
5 CoreFoundation 0x35bb8090 _CFXNotificationPost + 1400
6 Foundation 0x34fee3e4 -[NSNotificationCenter postNotificationName:object:userInfo:] + 60
7 Foundation 0x34fefc14 -[NSNotificationCenter postNotificationName:object:] + 24
8 UIKit 0x335120e6 -[UIApplication _performMemoryWarning] + 74
9 UIKit 0x335121e0 -[UIApplication _receivedMemoryNotification] + 168
10 libdispatch.dylib 0x33ffb252 _dispatch_source_invoke + 510
11 libdispatch.dylib 0x33ff8b1e _dispatch_queue_invoke$VARIANT$up + 42
12 libdispatch.dylib 0x33ff8e64 _dispatch_main_queue_callback_4CF$VARIANT$up + 152
13 CoreFoundation 0x35c332a6 __CFRunLoopRun + 1262
14 CoreFoundation 0x35bb649e CFRunLoopRunSpecific + 294
15 CoreFoundation 0x35bb6366 CFRunLoopRunInMode + 98
16 GraphicsServices 0x33951432 GSEventRunModal + 130
17 UIKit 0x3338ecce UIApplicationMain + 1074
18 MY Game 0x00079a90 0x75000 + 19088
19 MY Game 0x00079a50 0x75000 + 19024
As i understand from crash log, crash not happen due to my code. It's due low memory. Is that correct? How to find where the crash happen? Any suggestions.
As i understand from crash log, crash not happen due to my code. It's due low memory. Is that correct?
No, that's not correct.
Low memory is being reported, but your view controller is not responding properly. The most common cause of this is a retain cycle - see UIViewController purgeMemoryForReason: Crashing on iOS 5. In that answer, the retain cycle is in SVPullToRefresh , but yours could be elsewhere. The most common cause of retain cycles is not setting a delegate property to weak.
Once you figure out where the issue is, you can set breakpoints in viewDidUnload and ``didReceiveMemoryWarning`, simulate a memory warning, and step through your code to find the error.
Symbolication
Additionally, this crash report isn't symbolicated. Typically you'll want to symbolicate your crash report first. For example, see these lines:
18 MY Game 0x00079a90 0x75000 + 19088
19 MY Game 0x00079a50 0x75000 + 19024
In this case, as pointed out by Kerni, those two will just show start and main, so they won't help you in this instance. But generally, you should symbolicate your crash reports. (Search for "Xccode symbolicate crash logs" if you don't know how to do this.)
I have been getting rather strange crash reports from my live app with stack traces like the following:
Thread 0: Crashed: com.apple.main-thread
0 libobjc.A.dylib 0x38af7942 realizeClass(objc_class*) + 117
1 libsystem_malloc.dylib 0x390dbef5 szone_malloc_should_clear + 1376
2 libobjc.A.dylib 0x38af976f lookUpImpOrForward + 74
3 libobjc.A.dylib 0x38af1feb _class_lookupMethodAndLoadCache3 + 34
4 libobjc.A.dylib 0x38af1db9 _objc_msgSend_uncached + 24
5 UIKit 0x30e571bf __57-[_UIDelayedPresentationContext beginDelayedPresentation]_block_invoke + 26
6 libdispatch.dylib 0x38fd9d07 _dispatch_client_callout + 22
7 libdispatch.dylib 0x38fe2803 _dispatch_source_invoke$VARIANT$mp + 262
8 libdispatch.dylib 0x38fe073d _dispatch_main_queue_callback_4CF$VARIANT$mp + 188
9 CoreFoundation 0x2e3ef819 __CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__ + 8
10 CoreFoundation 0x2e3ee0ed __CFRunLoopRun + 1300
11 CoreFoundation 0x2e358c27 CFRunLoopRunSpecific + 522
12 CoreFoundation 0x2e358a0b CFRunLoopRunInMode + 106
13 GraphicsServices 0x3302c283 GSEventRunModal + 138
14 UIKit 0x30bfc049 UIApplicationMain + 1136
This is rather mysterious because neither the main thread nor any of the other live threads in the reports seem to imply that this is caused by my code, though of course I am skeptical of this.
This seems to be a rather common crash according to the number of reports I receive from Crashlytics, yet I have not been able to reproduce it on my own devices. I suspect this is probably related to some memory management issues because the various crashes always end up being some bad pointers being sent messages.
This always happens on this thread and following the -[_UIDelayedPresentationContext beginDelayedPresentation]_block_invoke call. This is obviously a private class being referenced from within some Apple framework, however I am at a loss to figure out exactly which one could be calling this.
The app is an educational game and I suspect this could be related to the GameKit API (particularly the Game Center authentication dialogs).
All of these crashes have been happening exclusively on iOS 7 and on iPad only. The app is universal so it is interesting to see that iPhone users seem to be unaffected.
Does anybody have any previous experience with these private classes that could give me some hints?
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.