Re: Garbage collection leak in simple Core Data application
Re: Garbage collection leak in simple Core Data application
- Subject: Re: Garbage collection leak in simple Core Data application
- From: Bill Bumgarner <email@hidden>
- Date: Fri, 28 Nov 2008 10:10:56 -0800
On Nov 28, 2008, at 8:49 AM, Mathieu Coursolle wrote:
Here is the result from gc-roots for a window controller that was
not collected:
(gdb) info gc-roots 0x1048c10
Number of roots: 1
Root:
0 Kind: stack rc: 0 Address: 0xbfffee24 Frame level: 3
Symbol: <unknown>
1 Kind: object rc: 0 Address: 0x01047be0 Class: NSWindow
ivar: NSResponder
2 Kind: object rc: 0 Address: 0x01048c10 Class:
MyWindowController
(gdb) info gc-references 0x1048c10
0 Kind: object rc: 0 Address: 0x01047be0 Class: NSWindow
ivar: NSResponder
1 Kind: object rc: 0 Address: 0x01047be0 Class: NSWindow
ivar: NSResponder
2 Kind: object rc: 0 Address: 0x01047be0 Class: NSWindow
Offset: 0x0000001c
3 Kind: object rc: 0 Address: 0x01048c10 Class:
MyWindowController ivar: NSWindowController
warning: can't find class named `NSWindowAuxiliary' given by ObjC
class object
4 Kind: object rc: 0 Address: 0x01066eb0 Offset: 0x0000002c
Class: NSWindowAuxiliary
warning: can't find class named `NSButtonCell' given by ObjC class
object
5 Kind: object rc: 0 Address: 0x0106f9f0 Offset: 0x00000018
Class: NSButtonCell
Should I understand that some unknown object keeps a reference to
the window, which keeps a reference to my window controller?
Unfortunately, I am not sure of how to interpret that result.
The roots are the interesting bit. The references are interesting,
too, but not for debugging this particular issue.
So -- there is a variable on the stack in frame 3 that is holding a
reference to the NSWindow, which is holding a reference to your
controller. More likely than not, this is happening because that
particular slot on the stack isn't being cleared. GCC's ABI specifies
that it *owns* the stack. That is; there is no way to know what is
where on the stack and, thus, the collector must scan the entire stack
to see if object references are lurking within.
Since the stack layout cannot be known and since the stack isn't
normally automatically zeroed, this can lead to stray references
sitting around for a while. In Leopard, the AppKit's main event loop
does automatically zero the stack from the top of the event loop, but
there can be some slots that sit *above* the zeroed area that will
hang around for a bit.
What happens if you open/close another document window? Does the
above go away? How about if you select a random menu item (info
window)? Does it go away then?
If it does, then you are running into this issue and there isn't a
huge amount that can be done. Upon tear down of the document, you
could explicitly set the window controller of the window to nil. The
window might stick around a bit longer, but the controller won't.
Yes, it can't be done in -finalize. But -finalize is generally
something to work hard to avoid having to write anyway.
b.bum
BTW: The output of roots and references looks wrong. The ivar field
seems to be spewing the wrong label....
_______________________________________________
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