Re: Years-old mysterious bindings crash
Re: Years-old mysterious bindings crash
- Subject: Re: Years-old mysterious bindings crash
- From: Quincey Morris <email@hidden>
- Date: Tue, 04 Oct 2011 18:41:20 -0700
On Oct 4, 2011, at 17:59 , Seth Willits wrote:
> There aren't any bindings setup at the point it crashes. The controller is connected to absolutely nothing. It literally is
>
> controller = [[NSObjectController alloc] initWithContent:nil];
> ... unrelated things ...
>
> [self view];
>
> In awakeFromNib:
> [controller setContent:obj];
> kaboom.
>
>
> The evidence I have supports that KVO has a rogue registration in it. I have new evidence for that, which I'm still working through. I'll post about that later when I know more.
>
> I magically did manage to make the thing crash today while opening a ton of windows and tabs while connected to Instruments trying to find a leak. I tried to replicate it... can't. It's so rare. I've opened hundreds and hundreds of windows and tabs and closed them in all kinds of random orders...
Aren't there things in the nib file itself that are bound to or through the object controller? I assumed so, since otherwise there's likely no point to have the controller at all. That would mean there are bindings existing before the setContent:, which of course dead-end at a nil object in the key path until you get everything connected. Maybe one of those is dysfunctional in an unexpected way.
It's also possible that the setContent: triggers a series of steps internal to the object controller, including the creation of private auxiliary objects and multiple observations. The stack trace makes things look like a single property change notification is trying to occur, but it ain't necessarily that simple.
The only other straw I can think of to grasp at is the timing of the setContent: in the above code sequence. We've been encouraged away from doing things at awakeFromNib time when there is an xxxDidLoad alternative. Now, NSViewController doesn't *have* a viewDidLoad, but the equivalent would be to do things after [super loadView] returns, and in your above sequence, that would actually be after [self view] returns. Is it a functional possibility to do the setContent: at that point instead of in awakeFromNib?
That wouldn't really apply to your other scenario, but it's the best ridiculous idea I can come up with.
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden