Re: [Leopard] Debugging GC
Re: [Leopard] Debugging GC
- Subject: Re: [Leopard] Debugging GC
- From: Bill Bumgarner <email@hidden>
- Date: Mon, 29 Oct 2007 13:25:04 -0700
On Oct 29, 2007, at 10:27 AM, John Stiles wrote:
On Oct 29, 2007, at 8:33 AM, Bill Bumgarner wrote:
On Oct 29, 2007, at 4:59 AM, Pierre Bernard wrote:
I am currently working on my first GC-enabled application.
Excellent!
When I start the application I get the following console output in
Xcode:
HoudahSpot2(20753,0xb0103000) malloc: free_garbage: garbage ptr =
0x105e7c0, has non-zero refcount = 1
HoudahSpot2(20753,0xb0103000) malloc: free_garbage: garbage ptr =
0x10696e0, has non-zero refcount = 1
What can I do about this? How does one debug this?
This means that something somewhere had CFRetain()'d something and
not CFRelease()'d it before the collector determined that the
something -- the collector is not limited to Objective-C objects --
is garbage eligible for collection. It is generally harmless.
While -retain/-release/-autorelease are no-ops under GC, CFRetain()
and CFRelease() are not.
In other words, this is a bug in the Apple supplied frameworks.
There is a radar tracking it and it'll be fixed.
It sounds like the garbage collector is also acting as a leak
detector! That's a useful feature :)
I glossed over some details.
Specifically, what is happening is that an object is being CFRetain'd
after the collector has already thrown it into the garbage list; has
already determined that it is collectable.
(Keeping in mind that "object" does not mean "objective-c object" but
"chunk of allocated memory which may or may not be an obj-c object").
This can happen because something is allocating or CFRetain'ing memory
during finalization and then not CFRelease'ing it. Bad code, no coffee!
The collector quite explicitly does not support resurrection and
retaining-without-releasing-during-finalization effectively leads to a
resurrection situation.
Although, if retain/release/autorelease are no-op'ed but CFRetain
and CFRelease are not, won't that cause problems in that regard?
e.g. if I have some code that creates an NSString and passes it to
an OS library that takes a (toll-free-bridged) CFString, my calls to
update its refcount will be ignored, but the OS library calls to
update the refcount will be honored… so I can envision many
different scenarios where refcounts could easily get munged up.
Yes, that can happen, but it doesn't cause a problem in correctly
written code, nor does it make anything worse in incorrectly written
code.
Specifically, if you have a strong reference to an object, that object
will not be collected. If an object is CFRetained, it will not be
collected. If CFRelease is called and the reference count drops to
0, the object will be eligible for collection (it may not be collected
right as the reference count drops to zero). If you destroy the
last scanned reference to an object but there is still a retain count,
the object will not be collected until sometime after the release.
b.bum
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden