Re: Bug in CF/NSString's no-copy constructors

FROM : John Engelhart
DATE : Fri Feb 08 03:31:49 2008

On Feb 6, 2008, at 1:29 PM, Michael Tsai wrote:

> On Feb 6, 2008, at 12:46 PM, Alastair Houghton wrote:
>

>>> I don't think this is a bug. The NSString and CFString APIs do not 
>>> indicate that they treat the bytes as scanned memory.

>>
>> That's true, but it doesn't matter whether they treat the bytes as 
>> scanned memory or not; that would only change whether putting 
>> pointer data in the bytes was safe.  The problem is whether the 
>> pointer itself is being traced, which isn't happening right now

>
> Sorry, that's what I meant.
>

>> the docs *do* say (in the Garbage Collection Programming Guide) 
>> that NULL, kCFAllocatorDefault and kCFAllocatorSystemDefault cause 
>> objects to be allocated in the GC zone, so I don't think it's 
>> unreasonable to expect that the pointer will be traced.

>
> The string was allocated using kCFAllocatorDefault, but the 
> deallocator was specified as kCFAllocatorNull. The docs say:
>
> "If the buffer does not need to be deallocated, or if you want to 
> assume responsibility for deallocating the buffer (and not have the 
> CFString object deallocate it), pass kCFAllocatorNull."
>
> If CFString is not going to be responsible for deallocating the 
> buffer, then it would not make sense to rely on CFString keeping the 
> buffer alive for you.


Just a quick note... my recollection is that using anything but 
kCFAllocatorNull results in a double free()... but I might be 
misremembering, it was awhile ago, but I'm pretty sure that this was 
the bit of code that did it.  A quick peek at the source code base 
shows this is only one of a handful of places where 
NSAllocateCollectable is used, so chances are this is it.  I think you 
also need to crank up the malloc environment debugging to catch it.