Weird NSOutlineView crash

Question

I'm experiencing weird crash in NSOutlineView: when i click "collapse" button, app crashes immediately and even "exception breakpoint" doesn't help to see where the problem is.

I've tried to run app without debugger, and reproduced the problem. Once app crashed, i've got OSX crash window and was able to extract crash message from there:

The window has been marked as needing another Update Constraints in Window pass, but it has already had more Update Constraints in Window passes than there are views in the window

there also call stack, but it won't help since crash happening inside libsystem_c.dylib, so i'm not posting it here.

It seems there is something wrong going with auto layout. Absolutely have no idea about next steps. Please give me an advice!

Also, one more thing, that began only after update to OSX Mojave.

Vogt

From the Xcode menu bar, choose Product > Scheme > Edit Scheme. Choose “Run” in the list on the left. then choose the “Diagnostics” tab in the area on the right. Turn on the checkboxes next to “Address Sanitizer” and “Zombie Objects”. Click “Close”. Run your app and try to reproduce the problem. Do you get more information with these options set? – Runofthemine

@robmayoff no. app was crashing earlier than i've got any useful debug info. – Vogt

I have the exactly same problem. How did you go around this? For my I have NSTextView, and it is crashes when I put a long text there. – Ottoottoman

Answer 1

After hours of debugging and testing, i noticed that that message is caused by "infinite layout loop".

Different code, related to outline view was causing NSSplitView to layout. And delegate method - (CGFloat) splitView:(NSSplitView*)sender constrainMinCoordinate:(CGFloat)proposedMinimumPosition ofSubviewAt:(NSInteger)dividerIndex has been called about 200 times prior to crash.

It's hard to catch this bcs it's not actually infinite recursion, so just debugger doesnt help a lot. I just added simple code that helped me to identify the issue:

static int a = 0; NSLog(@"Layout: %d", a++);

Hope my experience will help somebody else!

Vogt

My - (NSRect)splitView:(NSSplitView *)splitView effectiveRect:(NSRect)proposedEffectiveRect forDrawnRect:(NSRect)drawnRect ofDividerAtIndex:(NSInteger)dividerIndex is being called infinitely. How did you get this fixed??? – Ottoottoman

I have the exact same problem with Mojave and the same error message, and also very similar infinite loop with SplitView's delegate. How did you end up solving this? – Ottoottoman

Turns out that I was updating colors for Mojave dark mode in drawRect:dirtyRect and that caused infinite loop in -(void)layout. I removed that code because I didn't need it, and that fixed it. – Ottoottoman

Answer 2

For anyone who is having the problem in Xcode 14 and macOS using SwiftUI: I just had the same crash by hiding a view with an animation. My main view contains two views, one view contained an empty ScrollView, which didn't cause a problem by itself, but by changing it's size it crashed. Just adding a basic Text within the ScrollView solved my problem and the app doesn't crash anymore.

Cyclops

Answer 3

I updated my build to IOS 14 and Mac OS 20.15.6 and the error went away.

Bondon

Answer 4

i started to have this bug on 13.4

for me the issue was using withAnimation to hide a view in the safeAreaInset of a sidebar (possibly underlying NSOutlineView)

replacing

withAnimation {
   isShown = false
}

with

.animation(.default, value: isShown)
    

fixed it

Ohl

Answer 5

try turning off 'Use Auto Layout' checkbox in nib (in File Inspector tab). May have to disable it for each and every view.

Also, unrelated, but Mojave forces you to use Core Animation. Most of my nibs have 'set wants layer' turned off. However, in one of my nibs I had a stray setWantsLayer checkbox checked. when I unchecked it, the view (NSSearchField) drew properly

Vasiliu

Unfortunately, i cannot turn off auto layout. I have few hundreds XIBs. And i cannot update the app completely :( – Vogt

Also, didn't get you about Core Animation. What means Mojave forces to use CA? – Vogt

If I enable Core Animation using[ [window contentView] setWantsLayer:YES], my repeated re-display problems go away. If I don't enable Core Animation, Apple logs weird messages "ERROR: The window has been marked as needing another Display Window pass, but it has already had 3 Display Window passes." Also, I notice Mojave windows get drawn inside of a CATransaction, rather than the old [window displayIfNeeded] pathway. – Vasiliu