Re: [Leopard] Debugging GC
Re: [Leopard] Debugging GC
- Subject: Re: [Leopard] Debugging GC
- From: John Stiles <email@hidden>
- Date: Mon, 29 Oct 2007 10:27:11 -0700
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 :)
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.
_______________________________________________
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