Mailing Lists: Apple Mailing Lists

Image of Mac OS face in stamp
 
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Mysterious crash in CFSTR()



On Sat, 10 Mar 2007 01:35:03, Adin Hunter Baber <email@hidden>
wrote:

> Since Xcode 2.3, CFRetain() and CFRelease() have no effect on strings
> created via CFSTR().

Xcode version affects this? Not the OS version (where the program
runs) or SDK version (with which the program is built)?

While a good thing on a surface it doesn't look as good on the
second thought: I'm afraid this will encourage bad practices:
programmers will no longer be in a habit of "properly"
retaining/releasing CFSTRs. So one may write:

str = CFSTR("");
CFRelease(str);
//Continue using str

without a warnings in console or crash, etc. Not pretty. I'd prefer
a crash (or at least a warning) so it is harder to miss this and thus
easier to spot and to fix.

> Simple test:
> Create a CFString via CFSTR().
> Get its retain count.  The value is 0x10000000 I believe.
> Retain it.
> Check the retain count again.  No change.
> Release it.
> Check the retain count again.  No change.
> 
> BTW, this is a "magic number."  I did a test where I took a standard
> CFString, and kept retaining it until it hit the above number.  At
> that point CFRetain() and CFRelease() no longer had any effect.

Interesting. Thanks for sharing. BTW, a proper test will be to hit
the magic number and then try to release the object (once or even
several times in a row), not "retain/release" it. Otherwise you
don't know if this is a magic number or if this is just a masked
public value of a properly maintained private bigger (e.g. 64-bit)
refcount.

> On the other hand, I doubt many applications are going to need retain a
> string 2.7 billion times. :-D

It's only about 270 millions if it is exactly what you wrote above.
Quite big, but not very big: e.g. it is not impossible for an app
to have millions of entries in a databrowser list (that shows e.g.
a database contents) and consider that a particular column has the
same string or icon for all rows, so the single stringRef or iconRef
is shared. Better if the refcount limit would be close to the
"natural" limit of long, e.g. 0x7FFFFFFF. Anyway, I hope this is not
documented, so it is still an implementation detail that could be
changed (read: improved) anytime.

To the original poster. It might be a problem of your setup. Try
a minimal int main() { CFSTR(""); } app. If that works, start
with your original app and keep reducing it in binary cut matter -
that way you'll find a minimal app that still causes a crash.
At which point you'll probably have better idea what's going on.

Mike
[Available for hire. Resume on request.]


 _______________________________________________
Do not post admin requests to the list. They will be ignored.
Carbon-dev mailing list      (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/carbon-dev/email@hidden

This email sent to email@hidden

References: 
 >Re: Mysterious crash in CFSTR() (From: Adin Hunter Baber <email@hidden>)



Visit the Apple Store online or at retail locations.
1-800-MY-APPLE

Contact Apple | Terms of Use | Privacy Policy

Copyright © 2007 Apple Inc. All rights reserved.