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.
Related
I have completed developing a Swift application using iOS SDK 8.1 and it is now being tested by external testers via TestFlight as beta. Recently, I have received a crash report via Crashlytics with the following stack trace:
0 libobjc.A.dylib objc_msgSend + 28 setRefreshControlState:
1 libdispatch.dylib _dispatch_call_block_and_release + 24
2 libdispatch.dylib _dispatch_client_callout + 16
3 libdispatch.dylib _dispatch_after_timer_callback + 92
4 libdispatch.dylib _dispatch_client_callout + 16
5 libdispatch.dylib _dispatch_source_latch_and_call + 792
6 libdispatch.dylib _dispatch_source_invoke + 288
7 libdispatch.dylib _dispatch_main_queue_callback_4CF + 424
8 CoreFoundation __CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__ + 12
9 CoreFoundation __CFRunLoopRun + 1492
10 CoreFoundation CFRunLoopRunSpecific + 396
11 GraphicsServices GSEventRunModal + 168
12 UIKit UIApplicationMain + 1488
13 opsgenie AppDelegate.swift line 0 top_level_code
14 opsgenie AppDelegate.swift line 0 main
15 libdyld.dylib start + 4
I could not replicate the issue neither on my own device, nor on simulator and this crash has happened only once in three weeks. I have no idea about what may cause this crash and what this crash report means. I have also analysed my custom Crashlytics logs which are generated, however, everything seems normal and I still have no idea about the problem. I know it is nearly impossible to understand the problem by only having this stack trace on hand, but any recommendation/idea would be very useful.
you are using pull to refresh , while the content is loading user is going to another view hence the crash.try to replicate it on a slow connection while doing pull to refresh.you can make sure you handle startRefreshing, endRefreshing methods properly
I have an app build on the iOS8 SDK which I archive and then sign for adhoc distribution.
This has been working for 2 years on all devices with various updates. Now I have an iPhone 6 plus.
The app ran fine the first after a new install but now it keeps crashing with error:
"XPC API Misuse: Given object not of required type"
This happens before it gets into didFinishLaunchingWithOptions
Call stack:
Thread 0 name: XPC API Misuse: Given object not of required type. Dispatch queue: com.apple.main-thread
Thread 0 Crashed:
0 libxpc.dylib 0x0000000197dd99d8 _xpc_api_misuse + 60
1 libxpc.dylib 0x0000000197dd99d4 _xpc_api_misuse + 56
2 libxpc.dylib 0x0000000197dc9ae8 xpc_dictionary_set_value + 88
3 libxpc.dylib 0x0000000197dc5538 xpc_dictionary_set_string + 48
4 CoreFoundation 0x0000000186e4b590 _CFXNotificationRemoveObservers + 912
5 Foundation 0x0000000187d1ff20 -[NSNotificationCenter removeObserver:name:object:] + 252
6 UIKit 0x000000018b8588e4 -[UITableView dealloc] + 96
7 UIKit 0x000000018b6bf510 -[UIView(Hierarchy) removeFromSuperview] + 696
8 UIKit 0x000000018b79cb24 -[UIScrollView removeFromSuperview] + 76
9 UIKit 0x000000018b6c219c -[UIView dealloc] + 444
10 CoreFoundation 0x0000000186e217e4 CFRelease + 520
11 CoreFoundation 0x0000000186e2dda4 -[__NSArrayM dealloc] + 148
12 libobjc.A.dylib 0x0000000197599720 (anonymous namespace)::AutoreleasePoolPage::pop(void*) + 560
13 CoreFoundation 0x0000000186e25400 _CFAutoreleasePoolPop + 24
14 Foundation 0x0000000187d1f180 -[NSAutoreleasePool release] + 144
15 UIKit 0x000000018b72f9ac -[UIApplication _run] + 584
16 UIKit 0x000000018b72a980 UIApplicationMain + 1484
17 HelloWorld 0x000000010000636c main (main.m:16)
18 libdyld.dylib 0x0000000197beea04 start + 0
Can anyone help?
I fixed the crash in my own app but I can't 100% pin point the root cause. I suspect it was memory corruption or over retaining an object.
The key was [UITableView dealloc] I implemented dealloc in my table view to see where problem was occurring. I eventually traced it down to a UITableViewCell instantiated from a .xib file. This particular .xib contained multiple UITableViewCells. After giving each table view it's own .xib the crash disappeared.
for me, I got xpc api Misuse crash when I ran some video editing code from the simulator!(iOS 13), the problem doesn't appear on real device.
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.