On Jun 2, 2008, at 11:56 PM, Antonio Nunes wrote:
On Jun 3, 2008, at 8:46 AM, Bill Bumgarner wrote:
The actual loading is done like this:
self.masterPDFDocument = [[ANPDFDocument alloc] initWithURL:
absoluteURL];
If your -setMasterPDFDocument: -- synthesized or manually written
-- follows traditional reatain/release rules, the above will result
in the ANPDFDocument being over-retained.
The masterPDFDocument ivar is indeed a synthesized property, but the
app is garbage collected, so I would expect the reference to be
collected shortly after its host document is closed.
Yup -- that should be the case, then -- I didn't catch the part where
it was a GC'd app.
You can use gdb to figure out who is hanging on to the object for
longer than expected.
Print the address of it immediately after the above line of code.
Then, after closing the document and after hitting pause to drop into
gdb, try:
info gc-roots <address>
Now, this may spew objects that are too generic in nature. For
example, if NSApp shows up as the One True Root keeping your object
alive, that isn't very useful. In that case, you can use:
info gc-references <address>
This will show you all the objects -- all the scanned chunks of memory
(whether or not they are true Obj-C objects) -- that are referring to
your document. You can plug any one of those into gc-references to
figure out what is hanging onto *it*. It is sometimes necessary to
backtrack a reference or two to get to something sensible.
b.bum
_______________________________________________
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 [EMAIL PROTECTED]
