My App crashes randomly with this error:
[ServicesDaemonManager] interruptionHandler is called.
-[FontServicesDaemonManager connection]_block_invoke
(didReceiveMemoryWarning fires before the error message)
It is a bit hard to post code because of the randomness.
I use SwiftUI (UIHostingController), #ObserverObjects, async network calls, transitions to other views, etc.
It all works fine most of the time but sometimes i ran into this error.
The memory is then increasing constantly until the app crashes.
I tried to fix all possible memory leaks (to deallocate all images, [weak self], ...)
didn't help.
I'am not sure what the FontServicesDaemonManager is doing and in what way it is involved but all fonts are using the system font:
.font(Font.system(size: 25 , weight: .regular))
Sometimes also this error appears right after the one from obove:
-[UIWindow endDisablingInterfaceAutorotationAnimated:] called on <UIWindow: 0x10aab11a0; frame = (0 0; 375 812); gestureRecognizers = <NSArray: 0x10acb2510>; layer = <UIWindowLayer: 0x10aacbee0>> without matching -beginDisablingInterfaceAutorotation. Ignoring.
Anyone ran into similar issues or has an idea how to fix this?
(Xcode 11.6)
Update:
This problem is usually related to Autolayout constraints. Please check your constraints of all related views.
Hope you got the answer, I am here describing my scenario:
I got the same error with Xcode 11.6, the issue was I had enabled the zoombie object on scheme & it was creating [ServicesDaemonManager] interruptionHandler. So please check it. Reason behind memory warning was loading of high resolution images on mail thread which was not good. Adding download image in background thread worked for me.
Thanks,
Ratneshwar
This problem is usually related to constraints, there must be some ambiguity with your constraints, that's why you are getting this error.
Had the same issue with one of my collection views, because the constraints were not properly set for smaller screens. Check the constraints again and you will be good to go.
The problem i had was related to Autolayout and some constraints that did work for fullscreen for a specific view. I changed the Autolayout constraints and since then i had no crashes related to this issue anymore..
Related
I use 100% programmatic constraints in my interface code. Upgraded to Xcode 13 and iOS 15. Got tons of NEW execution warnings about constraints, all saying that the system had to break some constraints to comply with others. I had not seen such warnings for several years, and have not touched my constraint code in all that time. Yet thorough testing shows my code continues to run correctly. What's up?
Answer: I had been a bit cavalier with the timing of when iOS actually calculated the constrained dimensions. I put all of my programmatic interface declarations into a single method. At the bottom of that method, I have long had code that went beyond interface layout, into NavCon preliminaries. Among those NavCon declarations, I had lines like:
self.view_D0_Tutorial.frame = self.view_CenterPane_D0_Tutorial.frame;
I noted at the time that I wrote and debugged those lines, that using the debugger to ask what the location data was, all I ever got was CRect (0,0,0,0), yet the code somehow did the right thing.
Well, in the upgrade, iOS apparently changed the way they do things. I had to do two things in response.
(1) moved all the NavCon preliminary code to a new separate method, and call it with performSelector and 0 delay.
(2) changed the simple frame assignment to a more limited assignment:
self.view_D0_Tutorial.frame = CGRectMake(0, 0, self.view_CenterPane_D0_Tutorial.frame.size.width, self.view_CenterPane_D0_Tutorial.frame.size.height);;
The combination made the error messages go away, and my code continues to run correctly!
So I've worked on this App which should display a map, add annotations on coordinates found by Mapbox SearchUI, and start Navigating there when requesting it. It all worked fine until I opened xcode and tried to build today. I have the impression that MapBox updated Mapbox SearchUI (I am calling pod 'MapboxSearchUI', ">= 1.0.0-beta", "< 2.0" and it seems like XCode then uses 1.0.0-beta.2). Everything still works except one breaking thing: when trying to search stuff in the searchUI search bar, the app cant display the results, resulting in a timeout.
2021-10-13 13:51:15.300321+0200 APP[10454:5269100] [LayoutConstraints] Changing the translatesAutoresizingMaskIntoConstraints property of a UITableViewCell that is managed by a UITableView is not supported, and will result in incorrect self-sizing. Cell: <MapboxSearchUI.SearchSuggestionCell: 0x1138f7000; baseClass = UITableViewCell; frame = (0 0; 442 68); clipsToBounds = YES; autoresize = RM+BM; layer = <CALayer: 0x280d99980>>
2021-10-13 13:51:15.300463+0200 APP[10454:5269100] *** Assertion failure in -[MapboxSearchUI.SearchSuggestionCell _setHostsLayoutEngine:], NSLayoutConstraint_UIKitAdditions.m:3806
2021-10-13 13:51:15.301220+0200 APP[10454:5269100] *** Terminating app due to uncaught exception 'NSInternalInconsistencyException', reason: 'Must translate autoresizing mask into constraints to have _setHostsLayoutEngine:YES.'
Seems like XCode has trouble with MapBox's Layout for the results. This explains why searching from shortcuts such as Gas stations work fine since they don't need to display search results in the searchUI, doing it on the map instead.
Does anyone know how to work around this? Or is there a way to know what version exactly I was using a few weeks back? The weird thing is that I did not update the pods or mess with other parts of the project. It was on hold there and now it won't work anymore.
Thanks!
I've recently come across the same error message (and visual effect) in a codebase which does not use MapBox. The error started to occur only when the project was built using Xcode 13/iOS 15 instead of Xcode 12/iOS 14 (which was used before). The error only occurred on simulators/devices running iOS 15, not on iOS 14.
The codebase was, as the error message suggests, setting the translatesAutoresizingMaskIntoConstraints = false in multiple UITableViewCell's awakeFromNib() methods. Removing the line caused the error message to disappear and the contents to be displayed correctly on both, iOS 14 and iOS 15.
In your case, this will likely have to be addressed by the team at MapBox and a new SDK version would have to be provided including the change.
I'm posting here because I'm completely lost on this one.
I've searched all over the web, tried a lot of things myself, and searched weeks on this bug, but I can't find it.
So ever since iOS 11 (doesn't happen on iOS 10), everytime I press a button that activates the "show" segue in a UINavigationController the animation shows some weird padding at the top.
This padding disappears when the animation is finished.
I've changed the backgroundcolor of the superview to a red color, and the space you can see is indeed from the superview itself, so my guess is the whole UITableView is being moved down for some reason, although I'm not sure what exactly is the cause here.
(I'm using storyboard and AutoLayout constraints)
Another thing I noticed is that the spacing/padding you see is different on the iPhone X compared to the other devices (my guess is that it's the same height as the (non)safe area at the top? Again, not sure.
I don't think code is necessary to be provided here, as I wouldn't really know which part causes this behaviour (and there's a lot of code that I can't share for reasons..).
Any suggestions/help on how to fix this would be deeply appreciated!
Here are some examples:
iPhone X running iOS 11.1 (also happened on 11.0)
iPhone 8 gif
EDIT: I should add, some things I already tried:
tableView.contentInsetAdjustmentBehavior = .never
Setting headerviews to 0
tableView.setContentOffset(0, animated: false)
Playing with the translucency settings of the UINavigationBar
AutomaticallyAdjustContentInsets is set to false
So, as suggested by Spenser-Arn, I played around with the constraints and the Safe Areas, turns out, the safe areas where the cause of the issue.
Hope this helps other people as much as it helped me, and a big thankyou to Spenser-Arn!
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 have a UICollectionViewFlowLayout with an estimatedItemSize set.
When I run my application, everything works fine, but in my unit tests, I get an EXC_ARITHMETIC crash every time I hit collectionView:dequeueReusableCellWithReuseIdentifier:.
I know this is due to my estimatedItemSize as removing it fixes the crash.
Does anyone have any idea why this is happening?
Thanks
I have the same problem with UICollectionViewFlowLayout and estimatedItemSize. I filed a radar and Apple closed it as a duplicate with no further suggestions as a workaround. My best guess and research thus far indicates that self-sizing cells are fundamentally broken on iOS 8 / 9.
Try random values of estimatedItemSize. For me, setting sizes that closely match the resulting size of your cells cause a crash but sizes much smaller than your cells (1,1) for example do not crash.
I know this is not what you want to hear but it might be the only option until Apple fixes UICollectionView.