In my app I use UIPageViewController (PVC) with UIPageViewControllerTransitionStylePageCurl transition style and UIPageViewControllerSpineLocationMid spin location. So PVC shows two pages at a time.
I experience a rare crash when I try to scroll past the last pages. The log says:
Terminating app due to uncaught exception
'NSInvalidArgumentException', reason: 'The number of view controllers
provided (0) doesn't match the number required (2) for the requested
transition'.
I thought I did something wrong and tried to play around with Apple demo project (https://developer.apple.com/library/ios/samplecode/ZoomingPDFViewer/Introduction/Intro.html).
And the crash happened there too. It's hard to reproduce, you should scroll almost perpendicular to normal scroll axis (vertically).
My guess is that dataSource's methods got called in wrong order and messed PVC's integrity.
I got this order of calls:
2016-08-19 15:03:52.905 ZoomingPDFViewer[7469:1878917] next controller: nil
2016-08-19 15:03:53.358 ZoomingPDFViewer[7469:1878917] prev controller: <DataViewController: 0x14dd5b990>
2016-08-19 15:03:53.358 ZoomingPDFViewer[7469:1878917] prev controller: <DataViewController: 0x14dd42a50>
2016-08-19 15:03:53.373 ZoomingPDFViewer[7469:1878917] next controller: nil
So it seems PVC kind of wants to scroll and back and forth at the same time.
My question is there any way to workaround this problem? I can't think of any right now as dataSource's methods return correct data (so it seems).
The whole "scrolling both directions at once" thing is probably because of the bounce effect. Are you doing any sort of manipulation of the views on non-main threads?
UIPageViewController is kind of buggy as heck (and I'm being kind here) if you do anything even remotely nontrivial with it. You might read over my answer in Disable bounce effect in UIPageViewController and see if you're doing any of the things that the other answers to that question were doing.
Beyond that, I would suggest filing a bug. The more people file bugs against UIPageViewController, the more likely Apple is to fix it.
Related
I am getting random crashes while pushing to another view controller.
It was too difficult to find out such a crash, we spent the almost 2-3 days to solve this issue. seems like the crash was due to the one extra view outlet got connected to the main view in the storyboard. Which created the nil reference for some objects of the view controller and applications crashes.
But something surprising to us that how Xcode allowing me to connect the two outlets to the main view. I have again tried connecting the same but this time it is not allowing me to connect. Attaching the screenshot for the same.
Any kind of help/explanation is appreciated.
Please add crash logs. We should check them. Theres any data moving between two ViewControllers
It is problem with Xcode sometimes while editing the outlets.Find the controller on which app crashes and reconnect the outlets and run again.I don't know the exact reason but that solve my problem.
I keep getting EXC_BAD_ACCESS(code=1) intermittently. I've been trying to figure out what's wrong with this exception for hours but I have not been able to get to the bottom of it. The problem is that XCode doesn't really tell why it's crashing.
I have All Objective-C Exceptions set up with po $arg1 but the crash pointer still points to AppDelegate. Just to give you guys more info of what I am doing, I am creating dashboard with a pretty customized NSOutlineView that calls reloadData pretty frequently (every 5 seconds). The dataSource also gets updated before reloadData is called. I have suspicion that this concurrent updating of data and redisplaying it might be the issue but I am still not 100%.
When it crashes, it points to class AppDelegate: NSObject, NSApplicationDelegate.
The stackframe looks like:
When I click on frame 1, I get:
And the debug navigator
We've got an app that's fairly large now, and we recently upgraded to iOS 10. In doing so, a new bug was introduced, and we're at a loss for how to solve it.
The crash itself occurs during a call to layoutIfNeeded(). However, the crash does not occur unless the layoutIfNeeded() call is contained inside a UIView.animateWithDuration() block. No amount of weak referencing, delays, or dispatch calls seems to have any effect. The same crash can be triggered during a call to [super viewWillTransitionToSizeWithTransitionCoordinator].
"An Objective-C message was sent to a deallocated 'Bubble' object (zombie) at address: 0x10924f030."
Enabling Zombies shows that we have a Release call going to one of our UIView subclasses, which we've named Bubble. Nothing too special there, some layout constraints and a gesture recognizer.
The Instruments app hasn't helped much, nor has the new visual memory debugger in Xcode 8 (though it is awesome, surprisingly little documentation on the feature).
I've included a screenshot of Zombies during the crash here. While I know the retain count can be misleading, there are certainly some confusing points to the trace, and we could really use some help diagnosing this.
Again, this code worked fine before iOS 10. We've been unable to find any notes from Apple about underlying changes to UIKit that may have had an effect.
Some more brief info: [Bubble cleanBubbles] simply iterates over the subviews of any view passed in, and removes the subview if its a Bubble class.
Apologies on certain violations of naming conventions, I'm sure there's plenty to criticize!
Thanks
I've got a TableViewController with static table; one of it's cells houses an UIView named graphArea. The view renders a chart, it's background and an axis line - all inside it's drawRect(). There are also two another views (sunView & markerView), that are made with Interface Builder and used for chart dynamics (moving marker line and point on touch events).
All worked buttery smooth until I've implemented and tried to test a share button, that employs the ordinary activityViewController mechanism.
The magic begins, when one from a couple of share activities, whose share plugin window takes the full screen, is finished (no matter whether sharing succeeded or cancelled). The app crashes.
Discovery using debugger made apparent to me, that the crash happens, because some views, including graphArea, sunView, markerView are nil after return from sharing screen.
Only some of fullscreen share plugins (like preinstalled Mail and Messages, or, in my case, "Download to DropBox" action) lead app to crash. Other fullscreen share plugins do not (tested Telegram, WhatsApp, Skype). No one of those non-fullscreen plugins has ever caused crash (Evernote, Twitter, 2Do etc.).
It looks like graphArea, sunView, markerView are deallocated from memory when "malicious" share plugins take full screen. I haven't figured out, why.
Here's some debug info:
The traceback and assembly of fatalErrorMessage.
The next screenshot shows a part of controller code and properties, that are nil on return from share plugin (gray selection). And yes, they were all non-nil before.
Please, help me! Thank you in advance!
Thank you, Palpatim. My friend also pointed me at the same thing: I've put graphArea.removeFromSuperview() in viewDidDisappear(), and this caused the exception after share plugins, that have .presentationStyle = fullScreen. So at the point, when the app is to show again, there is no more graphArea in on the tableView.
I have an iPad app that has been running fine until iOS7. This issue seems to be only on ipad 2nd gen models and earlier when iOS7 is installed. Anyway, I've been tearing my hair out trying to figure out where this error is coming from, but have had no luck. The console in xcode (5) reports the following error after I perform a logged in segue:
2013-11-18 11:17:31.768 MyApp[400:60b] *** -[UIToolbar backdropView:willChangeToGraphicsQuality:]: message sent to deallocated instance 0x18ec23e0
I can't lookup the address for more info (image lookup -a 0x18ec23e0) it just returns nothing.
In instruments running zombies, it reports that a message was sent to a UIToolbar like so:
When I inspect the instance, I get the following:
How do I debug this? I have no idea where this call is being made and it seems dependent upon a physical deivce (doesn't happen on the iPad mini or ipad 3/4)
I was struggling with a very similar error, also with a UIToolbar, that I couldn’t figure out until a couple hours ago. I also had to use and try to understand the zombies’ instrument but without any luck.
What I did was to pay a close attention to the call stack that was presented when the Exception Breakpoint was activated as described in the following tutorial:
http://www.raywenderlich.com/10209/my-app-crashed-now-what-part-1
Even though the call stack didn’t point me to the exact code line, I noticed that the app was trying to add a UIToolbar to a ViewController. Turns out that what I was doing was creating a local UIToolbar inside of a method and adding it to the presented UIView. After have modified this behavior, I stopped having the annoying sudden crash. It was difficult for me to find the issue because looking at the code of the ViewController that caused the crash, there was no code that created or used a UIToolbar; however this VC included a custom view that did exactly that, as I explained before.
Have said all of this I recommend you to closely inspect the VC that generates the crash. If you need to create a UIToolbar programmatically I recommend you to declare it as a strong property to maintain the memory reference as long as needed.
I hope this helps you.
I struggled with this for a while today. I had two storyboards, one for login/signup (set as the main storyboard for the project) and another with the rest of the application. The app delegate would detect if a user was logged in and instantiate the root view controller of the other storyboard. The root view controller of the login storyboard is a navigation controller and after after some investigation with instruments I realized there was a UIToolbar being instantiated from the nib. Opening up the storyboard file revealed an off-screen UIToolbar object in the root view controller. I deleted it and I'm not crashing any more.
I should also mention this crash was only occurring when I was using MKMapView.