On Jun 3, 2008, at 9:13 AM, Bill Bumgarner wrote:
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.
Thanks Bill,
That was really useful. I was indeed holding a reference to the
document in the app's inspector panel, which would only be cleared if
and when another document was opened or switched to. After ensuring
this reference gets cleared when the document is closed, both the gc-
roots and gc-references return no results, which sounds just about
right.
However: the original issue was not resolved by this fix. I ran the
app through Instruments with ObjectAlloc and it shows that after
closing the document my NSDocument subclass instance is indeed
cleared. However, moving the original PDF document to the trash and
then emptying the trash, the document is still being reported as in
use. A closer look at the traces in ObjectAlloc shows that the
CGPDFDocument along with its CGPDFPage objects, which PDFKit creates
when it reads in the document from disk, are not released.
(PDFDocument's initWithURL: method calls
CGPDFDocumentCreateWithProvider.) I can get the CGPDFDocument's
address in ObjectAlloc, but when running thus, I can't pause the
application to get the info gc-roots listing. If I run a normal debug
session in Xcode, I don't know how to get the address for the
CGPDFDocument that underlies the PDFDocument. So it is difficult to
find out what is holding on the the CGPDFDocument (and/or its pages).
António
-----------------------------------------------------------
Don't believe everything you think
-----------------------------------------------------------
_______________________________________________
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]
