On Oct 21, 2009, at 01:39, Nick Rogers wrote:
When I set this ivar to nil. the results are:
(gdb) info gc-roots 0x2004f9340
Number of roots: 1
Root:
0 Kind: bytes rc: 1 Address: 0x0000000200543b40 Offset:
0x0000000000000008
1 Kind: object rc: 0 Address: 0x00000002004f9340 Class: Volume
So there's still a live pointer to your Volume instance in a block of
(GC-controlled) memory at 200543b40+8. That block appears to be alive
because it has a non-zero reference count.
Note that non-Cocoa frameworks such as Core Foundation can return
objects/memory with a non-zero reference count, even under GC.
CFRetain and CFRelease (and the related CFMakeCollectable and
NSMakeCollectable) manipulate these reference counts, even under GC.
Thus, for example, if you create a CFArray under GC you still need to
CFRelease it before it can actually be garbage collected.
I don't see enough information here to find out why your object is
still referenced. Your problem may be as simple as putting your Volume
instance in a leaked CFArray or CFDictionary. Or, something in your
code or in the frameworks may genuinely still be using your Volume
instance.
In the absence of further information, the simple-minded approach to
solving this would be to use the debugger to watch what happens to
your Volume instance from its creation, and find out when the extra
reference appears. Knowing when might tell you why.
_______________________________________________
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
