Cocoa mail archive
Re: Bug in CF/NSString's no-copy constructors
FROM : Alastair Houghton
DATE : Wed Feb 06 18:46:09 2008
On 6 Feb 2008, at 16:46, Michael Tsai wrote:
> On Feb 6, 2008, at 10:55 AM, Alastair Houghton wrote:
>
>> I'll just add, publicly, that I think this probably is a bug in
>> CFString that John has found here. That is, I don't see why
>> CFString's pointer shouldn't be traced by the collector in this
>> case (it doesn't appear to be; certainly when I try it the backing
>> buffer is released). The problem also occurs with NSString's -
>> initWithBytesNoCopy:length:encoding:freeWhenDone: et al.
>
> 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; 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.
> In fact, when you pass in kCFAllocatorNull you are telling CFString
> that you "assume responsibility for deallocating the buffer." At the
> end of -someMethod, you haven't saved a __strong reference to the
> buffer, so the collector is allowed to free it.
It's *an* argument, certainly.
I just think that there's no harm in making the pointer visible to the
collector; it doesn't hurt if the pointer isn't pointing into the GC
pool. And it would mean that you could pass a chunk of memory
allocated using NSAllocateCollectable(), which seems not
unreasonable. I don't think it's hugely important, since you can
always use malloc() and let it call free() (which will happen
automatically), but if it's an easy fix then it's probably worth
doing. Not that many people will do this or indeed should be doing
this kind of thing.
Anyway, at the very least it's worth drawing to the attention of
whoever's responsible for CFString at Apple. If they want to fix it,
great. If not, the docs could be updated to say that you shouldn't
pass GC'd memory into those APIs.
If we could see the sources for CFString, we could probably make a
better determination as to whether this was worth fixing. But
currently the CF project's sources aren't visible (for Leopard) :-(
Kind regards,
Alastair.
--
http://alastairs-place.net
DATE : Wed Feb 06 18:46:09 2008
On 6 Feb 2008, at 16:46, Michael Tsai wrote:
> On Feb 6, 2008, at 10:55 AM, Alastair Houghton wrote:
>
>> I'll just add, publicly, that I think this probably is a bug in
>> CFString that John has found here. That is, I don't see why
>> CFString's pointer shouldn't be traced by the collector in this
>> case (it doesn't appear to be; certainly when I try it the backing
>> buffer is released). The problem also occurs with NSString's -
>> initWithBytesNoCopy:length:encoding:freeWhenDone: et al.
>
> 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; 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.
> In fact, when you pass in kCFAllocatorNull you are telling CFString
> that you "assume responsibility for deallocating the buffer." At the
> end of -someMethod, you haven't saved a __strong reference to the
> buffer, so the collector is allowed to free it.
It's *an* argument, certainly.
I just think that there's no harm in making the pointer visible to the
collector; it doesn't hurt if the pointer isn't pointing into the GC
pool. And it would mean that you could pass a chunk of memory
allocated using NSAllocateCollectable(), which seems not
unreasonable. I don't think it's hugely important, since you can
always use malloc() and let it call free() (which will happen
automatically), but if it's an easy fix then it's probably worth
doing. Not that many people will do this or indeed should be doing
this kind of thing.
Anyway, at the very least it's worth drawing to the attention of
whoever's responsible for CFString at Apple. If they want to fix it,
great. If not, the docs could be updated to say that you shouldn't
pass GC'd memory into those APIs.
If we could see the sources for CFString, we could probably make a
better determination as to whether this was worth fixing. But
currently the CF project's sources aren't visible (for Leopard) :-(
Kind regards,
Alastair.
--
http://alastairs-place.net
