Re: NSCFArray autoreleased with no pool in place
Re: NSCFArray autoreleased with no pool in place
- Subject: Re: NSCFArray autoreleased with no pool in place
- From: Tron Thomas <email@hidden>
- Date: Fri, 15 May 2009 20:00:52 -0700
Greg Parker wrote:
On May 14, 2009, at 9:58 PM, Tron Thomas wrote:
That did the trick. The stack trace allowed me to track down the
cause of the error. Because Objective-C++ does not have a concept of
class static variables I had an NSArray defined in an anonymous
namespace in the implementation module that was initializing its
contents. I changed the code so the array is initially set to nil in
the anonymous namespace, and then assign it to an NSArray instance
the init method of the class using the array if the array had not
been initialize.
I'm guessing the code you just wrote is not thread-safe - if two
threads are simultaneously the first to call -init then things might
go wrong. If you need thread-safe initialization, the +initialize or
+load methods are usually better.
I looked into trying to use +initialize or +load to set the values of
the array, as I thought it might be a better approach than using the
-init function.
When I used +load, I get the same problem I had before the array is
getting setting before the main function executes and creates an
auto-release pool.
When I use +initialize the program crashes when it tries to access the
array later on in the program life cycle. It seems like the array
becomes corrupt. For some reason the debugger thinks it is an
NSCFNumber instance instead of an array.
What might be going wrong that is preventing +initialize from
successfully creating the array?
_______________________________________________
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