Hi Graham, Many thanks for the reply, much appreciated. The strange thing with this one is that I've been through the code in all the obvious places and I can't find that it's been retained anywhere. It's an NSArrayController subclass that is only really used in one place in the application, and any other object that accesses it does so through the main window controller. It's not added as a represented object anywhere. The only thing I can think is that it as it is instantiated in Interface Builder, it is being retained through its bindings somewhere in certain circumstances. After posting I thought I had narrowed in on it a little bit - I found a circumstance in which it seemed to crash every time. But then it stopped crashing again even though I'm doing exactly the same thing... Very strange.
I'm curious that you say that the "true cause" is the stale pointer to the document. I could fix this part easily, but have avoided doing so because it was my understanding that although the stale pointer was indeed the cause of the crash, the true bug was this object not getting released properly. So I was leaving it to crash in this situation in the hope of finding the underlying problem (fortunately this is in a beta version of the next version of the product rather than in the official release version). Thanks again and all the best, Keith --- On Thu, 2/4/10, Graham Cox <[email protected]> wrote: > From: Graham Cox <[email protected]> > Subject: Re: Debugging (apparently) random retain loop bug (NSArrayController) > To: "Keith Blount" <[email protected]> > Cc: [email protected] > Date: Thursday, February 4, 2010, 11:10 PM > > On 05/02/2010, at 7:21 AM, Keith Blount wrote: > > > Occasionally, if you close a document (NSDocument > subclass) in my app and then open another document (or > reopen the same document), the app crashes. I've debugged > this to the extent that I now know the cause, at least. What > is happening is that sometimes when a document gets closed, > a particular NSArrayController subclass instance isn't > getting deallocated - but only sometimes. Then, when another > document gets loaded, one of the notifications it sends out > is picked up by the array controller still in memory which > was registered as an observer for that particular > notification; the array controller then tries to call out to > other parts of its associated document - but of course they > no longer exist, and neither should it, so it crashes. > [] > > > Has anybody got any good advice (or links to good > advice) on how to track down something like this? At the > moment I'm stumped because I can't seem to make it > reproduceable every time. > > I tracked down a crash in my app the other day which is an > exact clone of this - an object owned by the document wasn't > getting deallocated, then a later notification was picked up > by it, and referred to the now non-existent document. > > The cause is likely simple - something else is retaining > the owned object besides the document, and that retain is > still in force at the time the document is dealloc'ed. The > problem is to find who the hell is doing that - for me that > took a lot of detective work over several hours. The culprit > in my case turned out to be a menu in the main menu bar > holding the object as a -representedObject in one of its > menu items, but there's no reason why it would be exactly > that in your case. I tried overriding -retain so I could log > who was calling it but unfortunately that wasn't helpful, as > all sorts of things were retaining the object briefly so it > just led to a lot of noise. In the end it was a case of > narrowing down the circumstances that triggered the extra > retain and working through the code line by line - I got > lucky in that I realised it was access to any menu that led > to the bug. > > I also fixed the true cause of the bug - the object having > a stale pointer to the document. So in my document's > -dealloc method, I simply null out the secondary object's > reference to self (e.g. [secObject setOwner:nil];). That > should work for you as well. Then, even if something else is > retaining the secondary object, it isn't holding a stale > reference to the document, so while it will respond to the > notification as usual, it will message nil safely instead of > the stale document. In general you should null out any weak > "back pointers" like this when the true owner of an object > is dealloc'ed - in this case I'd overlooked this one, which > was the real bug, but the additional retain made it show > up. > > hth, > > --Graham > > > > _______________________________________________ Cocoa-dev mailing list ([email protected]) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [email protected]
