iOS 9, Swift 2: I've got a view controller with a custom view that crashes whenever I pop it from it's navigation controller stack, citing the following crash:
*** Terminating app due to uncaught exception 'CALayerInvalidGeometry', reason: 'sublayer with non-finite position [inf inf]'
There is far too much going on in the view controller to post here (it's what i'm in the middle of cleaning up) but was wondering if anyone has experienced a similar issue?
I've seen sublayer with non-finite position [inf inf] and a related question, but neither resolve the problem. There is no CGRectNull to be found in the entire code base, so i'm a bit stumped.
And of course as soon as I post the question after 30 minutes of struggling, I finally crack it.
There were a whole bunch of subViews that were being added to the view elsewhere in the view controller that I wasn't aware of. The main view is using constraints based layout while these subviews were being created with a frame and then added as a subview.
I'm not sure why it was causing a crash, but after removing all the rogue subviews all was well.
I'll keep this question/answer alive in case anyone else has the same issue.
Related
Answers to similar questions did not help so I'm opening a new question.
I have this issue in several of my projects now:
Tapping on the first responder UITextField or on a UITextView (that would normally bring up the default context menu for copy and paste) causes my app(s) to crash.
Note: UICalloutBarButton is a UIKit private API, so there is no chance to change its layoutSubviews implementation and call [super layoutSubviews] in it.
Log message:
*** Assertion failure in -[UICalloutBarButton layoutSublayersOfLayer:], /SourceCache/UIKit_Sim/UIKit-2935.137/UIView.m:8794
*** Terminating app due to uncaught exception 'NSInternalInconsistencyException', reason: 'Auto Layout still required after executing -layoutSubviews. UICalloutBarButton's implementation of -layoutSubviews needs to call super.'
I don't have any idea why this appears. Would be very happy for any help.
EDIT
Trying to reproduce the crash in a demo project I found out that it is a custom UIView category that causes the crash. See accepted answer for more details.
By trying to reproduce the crash in a demo project I found out that it is a custom UIView category that causes the crash.
When creating this fault, I assumed that category methods were only available for UIView subclasses that #import this category.
But this is not the case as described in the Apple Documentation:
Any methods that you declare in a category will be available to all instances of the original class, as well as any subclasses of the original class. At runtime, there’s no difference between a method added by a category and one that is implemented by the original class.
So not being aware of this, I had overridden in my custom category the UIView method + (BOOL) requiresConstraintBasedLayout to return YES (like I wrongly thought only for those classes that import this category).
Putting a breakpoint in that method, I learned that this 'category-method' gets called from everywhere in the UIKit once the category files are added to a project.
Nothing but a painful way of learning/accepting, that overriding methods in categories is never a good idea - unless you want to cause strange crashes like this ;-).
Sorry for stealing your time, but thank you for asking some code examples which forced me to seriously reproduce the problem - which lead me to the crash-cause...
Has anyone encountered this warning message related with autolayout:
All dependent constraints should have been removed from the engine and also from the view's list of dependent constraints
Currently, we have some footerView with several buttons inside and they are hidden or showed depending on the need. We use full autolayout everywhere. Here's the method for hiding/showing this footerView:
- (void)hideFooterView:(BOOL)shouldHide {
self.containerViewBottomConstraint.constant = shouldHide ? 0 : 50; // expand containing view to fit to full screen OR make it smaller to fit with footerView
[UIView animateWithDuration:1 animations:^{
[self.view layoutIfNeeded]; // animate expanding screen height to full height
[self.footerView setAlpha:(shouldHide ? 0 : 1)];
} completion:nil];
}
So, when this method is called for the first time then there's no error message. But after the second time mentioned warning appears in console. We can't ignore this warning because in other screens we are encountering crashes with private Apple method calls without any clue how to solve that:
[UILayoutContainerView nsis_shouldIntegralizeVariable:]: message sent to deallocated instance
here's another crash message:
[UILayoutContainerView nsis_valueOfVariable:didChangeInEngine:]: message sent to deallocated instance
I was unable to find anything useful related to "nsis_valueOfVariable:didChangeInEngine:" or "Autolayout dependent constraints" keywords on web. Any ideas?
UPDATE Commenting out line "[self.view layoutIfNeeded]" seems fixed the issue but then there will be no animation...
In my project also this issue came. I was getting same warning "All dependent constraints should have been removed from the engine and also from the view's list of dependent constraints".
As you told, when I ignored it and in other screens I got crashes, showing
[UILayoutContainerView nsis_shouldIntegralizeVariable:]: message sent to deallocated instance
I found that, in my case I was calling [self.view layoutIfNeeded] inside -(void)viewWillDisappear:(BOOL)animated. When I removed this out, the issue was fixed.
No warnings and no crashes.
From this what I understood is, if we call layoutIfNeeded just before the view is being deallocated this warning will come. And in next screens it will cause crashing.
It took so much time to figure out this crash. That's why I am sharing my thoughts.
This may help someone.
Is there a problem with adding a UITableView as a subview of aUIView? I had a line of code that was working for months, and recently broke after I updated XCode to 4.6.3. Long story short, I was returning TableViewTwo as a subview of a UIView as a footer of TableViewOne. Please don't ask me why this is necessary, it is just convenient for what I am doing. Well, the app would always crash on the simulator, but not on the device. It would give me a bizarre error and an opaque call stack. The error said unrecognized selector(numberOfSections)sent to instance. Yes, the selector was numberOfSections and not the numberOfSectionsInTableView in the UITableViewDataSource. Well, when I returned the UITableViewTwo as UITableViewOne's footer..everything started working. Does anyone know if there is a problem with adding a UITableView as a subview of a UIView? For more information - see this SO Post(link)
I had my LayoutConstraints working fine, then all of a sudden I started getting this when adding Constraints to my view.
*** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '*** +[NSLayoutConstraint constraintWithItem:attribute:relatedBy:toItem:attribute:multiplier:constant:]: Constraint must contain a first layout item'
*** First throw call stack:
(0x7cd012 0x2017e7e 0x7ccdeb 0xde6bf1 0x9c487 0x994a3 0x414fb 0x20224 0x5c6c0 0xc30e83 0x78c376 0x78be06 0x773a82 0x772f44 0x772e1b 0x28eb7e3 0x28eb668 0x149465c 0x2cfd 0x2c25)
libc++abi.dylib: terminate called throwing an exception
And there exists no immediate documentation on the internet or on the Apple Docs as to what the error message means.
Just wondering if anyone has encountered this error, and know what I can do to troubleshoot it?
One more reason for this error/crash can be, the views passed to the [NSLayoutContraint constraintWithItem ...] method are nil.
Ah, found the issue.
For anyone who has this issue, it's because the view hasn't been created in the nib/UIView yet, so no constraints can apply.
I moved the Constraint code from the initWithNib method to viewDidLoad and the error naturally stopped occurring.
If you're hanging on to your views with properties make sure they're strong! This could account for them being nil.
This can also happen if you switch off Autolayout for some reason, but you're still adding constraints to any subview via code (e.g. for handling orientation changes)
This happened to me when I used to different NIB's for the iPhone and iPad and switched off Autolayout for only the iPhone NIB while using a common .m file.
Solution is to check for the device type and skip the layout addition where it's not needed.
This happened when I accidentally deleted the 'referencing outlet' for one of my UI elements.
I tried removeFromSuperview on a view that had not been added as a subview but Xcode 4 didn't throw any error. Is this expected behaviour?
First off, Xcode 4 wouldn't do anything at all. That's the IDE. It has nothing to do with the runtime behavior of your app.
Secondly, the documentation for -removeFromSuperview states
If the receiver’s superview is not nil, the superview releases the receiver.
What part of this would lead you to expect -removeFromSuperview to throw an exception if the view has no superview?
In any case, the answer is yes, this is normal. -removeFromSuperview does not throw exceptions.