On Aug 9, 2011, at 21:33 , Shane Stanley wrote:
> info gc-roots 0x4011fcca0
> Number of roots: 7
> Root: #1
> 0 Kind: stack rc: 0 Address: 0x00007fff5fbfe288 Frame level: 1
> Symbol: <unknown>
> 1 Kind: object rc: 0 Address: 0x00000004011fcca0 Class: MyWindow
> Root: #2
> 0 Kind: stack rc: 0 Address: 0x00007fff5fbfe248 Frame level: 0
> Symbol: self
> 1 Kind: object rc: 0 Address: 0x00000004011fcca0 Class: MyWindow
> Root: #3
> 0 Kind: stack rc: 0 Address: 0x00007fff5fbfe238 Frame level: 0
> Symbol: it
> 1 Kind: object rc: 0 Address: 0x00000004011fcca0 Class: MyWindow
> Root: #4
> 0 Kind: stack rc: 0 Address: 0x00007fff5fbfe278 Frame level: 1
> Symbol: <unknown>
> 1 Kind: object rc: 0 Address: 0x00000004011fcca0 Class: MyWindow
> Root: #5
> 0 Kind: bytes rc: 1 Address: 0x0000000400efa2e0
> 1 Kind: object rc: 0 Address: 0x00000004011fcca0 Class: MyWindow
> Root: #6
> 0 Kind: stack rc: 0 Address: 0x00007fff5fbfe308 Frame level: 3
> Symbol: <unknown>
> 1 Kind: bytes rc: 1 Address: 0x0000000400efa2e0
> 2 Kind: object rc: 0 Address: 0x00000004011fcca0 Class: MyWindow
> Root: #7
> 0 Kind: stack rc: 0 Address: 0x00007fff5fbfe260 Frame level: 0
> Symbol: <unknown>
> 1 Kind: bytes rc: 1 Address: 0x0000000400efa2e0
> 2 Kind: object rc: 0 Address: 0x00000004011fcca0 Class: MyWindow
(I annotated the above with numbers on the roots.)
Starting at the bottom, the last 3 show strong references to the window from
object 0x0000000400efa2e0. *That* object is being kept alive by 2 stack
references (#6 and #7), but it's a root reference in itself. I wouldn't be
surprised if this is the window controller.
You don't happen to have a singleton pattern of some kind for the window's
window controller? I mean something like [MyWindowController
sharedWindowController]. The simplest implementation of that pattern doesn't
ever release the singleton.
The first 4 roots are all stack references directly to the window.
The next step is to try getting the debugger to tell you the class of the
referencing objects -- 'po [0x0000000400efa2e0 class]', etc.
Note that the only root that *isn't* a stack variable is #5, so that's the one
I would be suspicious of. (After all, at a certain point, you'd expect all the
stack frames that might have a variable referring to a window to be popped by
the time you get back to the main event loop, so stack references shouldn't
really be what's keeping this alive, unless a reference to the window has
migrated up to a stack frame above the main event loop.)
If you get nowhere useful with the debugger, you can try following up in
Instruments (Allocations and Leaks). If a window gets leaked for every document
you open (but isn't detected by Instruments as a leak), then the quickest way
to get a picture of what's going on is to use heapshot analysis:
http://www.friday.com/bbum/2010/10/17/when-is-a-leak-not-a-leak-using-heapshot-analysis-to-find-undesirable-memory-growth/
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
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 arch...@mail-archive.com
