• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Bug in CF/NSString's no-copy constructors
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


  • Subject: Re: Bug in CF/NSString's no-copy constructors
  • From: John Engelhart <email@hidden>
  • Date: Thu, 7 Feb 2008 21:31:49 -0500


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.


_______________________________________________

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


References: 
 >Use of Mac OS X 10.5 / Leopards Garbage Collection Considered Harmful (From: John Engelhart <email@hidden>)
 >Re: Use of Mac OS X 10.5 / Leopards Garbage Collection Considered Harmful (From: Alastair Houghton <email@hidden>)
 >Re: Use of Mac OS X 10.5 / Leopards Garbage Collection Considered Harmful (From: John Engelhart <email@hidden>)
 >Re: Use of Mac OS X 10.5 / Leopards Garbage Collection Considered Harmful (From: Alastair Houghton <email@hidden>)
 >Re: Use of Mac OS X 10.5 / Leopards Garbage Collection Considered Harmful (From: John Engelhart <email@hidden>)
 >Bug in CF/NSString's no-copy constructors (was Re: Use of Mac OS X 10.5 / Leopards Garbage Collection Considered Harmful) (From: Alastair Houghton <email@hidden>)
 >Re: Bug in CF/NSString's no-copy constructors (was Re: Use of Mac OS X 10.5 / Leopards Garbage Collection Considered Harmful) (From: Michael Tsai <email@hidden>)
 >Re: Bug in CF/NSString's no-copy constructors (From: Alastair Houghton <email@hidden>)
 >Re: Bug in CF/NSString's no-copy constructors (From: Michael Tsai <email@hidden>)

  • Prev by Date: Re: no method found returning 'id'
  • Next by Date: Re: libPng.dylib: "file is not of required architecture"
  • Previous by thread: Re: Bug in CF/NSString's no-copy constructors
  • Next by thread: Re: Use of Mac OS X 10.5 / Leopards Garbage Collection Considered Harmful
  • Index(es):
    • Date
    • Thread