On Aug 9, 2011, at 22:34 , Shane Stanley wrote:
In my document class's -makeWindowControllers I'm setting a property to the
window controller; could that be the problem?
A property of the document? Could be, but you'd have to track through the gc
info-roots to find out what's keeping what
On Aug 10, 2011, at 4:20 PM, Quincey Morris wrote:
f you're setting this property just for convenience (after all, you can find
the window controller later by examining [document windowControllers]), then
maybe you really want this property to be a weak reference?
Thanks for the suggestion.
I have a document-based application that uses garbage collection. It's
straight-forward in terms of having subclasses of NSDocument, NSWindow, and
NSWindowController, and documents have a single window (with drawer, if that
makes any difference).
But when I close a window/document, the window
On 2011 Aug 09, at 05:24, Shane Stanley wrote:
Any thoughts/suggestions?
See if -dealloc is running in your NSDocument subclass. Probably not. In that
case, it's you're whole document that's lingering, not just the window.
Never used garbage collection, so someone else will need to help
On Aug 9, 2011, at 05:24 , Shane Stanley wrote:
I have a document-based application that uses garbage collection. It's
straight-forward in terms of having subclasses of NSDocument, NSWindow, and
NSWindowController, and documents have a single window (with drawer, if that
makes any
On Aug 9, 2011, at 11:50 PM, Jerry Krinock wrote:
See if -dealloc is running in your NSDocument subclass. Probably not. In
that case, it's you're whole document that's lingering, not just the window.
Dealloc isn't called with GC, and the document isn't lingering -- it's just the
window.
On Aug 10, 2011, at 3:51 AM, Quincey Morris wrote:
It's not entirely clear what it is you're expecting here.
What I'm expecting is that when I close a document, the document, the window
controller and the window will disappear.
AFAICT -- and I have spent some time pondering the
On Aug 10, 2011, at 3:51 AM, Quincey Morris wrote:
use the debugger's 'info gc-roots' command (having set a breakpoint somewhere
after the window has been closed and the collector has had time to run,
preferably) to find out what's keeping the window alive.
So I get this:
info gc-roots
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: 0x7fff5fbfe288 Frame level: 1
Symbol: unknown
1 Kind: object rc: 0 Address: 0x0004011fcca0 Class: MyWindow
Root: #2
0 Kind: stack
On Aug 10, 2011, at 3:12 PM, Quincey Morris wrote:
Starting at the bottom, the last 3 show strong references to the window from
object 0x000400efa2e0. *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
10 matches
Mail list logo
