• 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: NSCFArray autoreleased with no pool in place
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: NSCFArray autoreleased with no pool in place


  • Subject: Re: NSCFArray autoreleased with no pool in place
  • From: Michael Ash <email@hidden>
  • Date: Fri, 15 May 2009 23:20:27 -0400

On Fri, May 15, 2009 at 11:00 PM, Tron Thomas <email@hidden> wrote:
> 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?

Post your code.

I could guess at what's going on, but what's the point? If you post
your code, then certainty is likely to occur.

Any time you (or anyone else) starts *describing* what your code does,
stop, open your editor, select the code in question, and copy/paste it
into your e-mail. It's easier for you, and it's easier for everyone
else.

Mike
_______________________________________________

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: 
 >NSCFArray autoreleased with no pool in place (From: Tron Thomas <email@hidden>)
 >Re: NSCFArray autoreleased with no pool in place (From: Clark Cox <email@hidden>)
 >Re: NSCFArray autoreleased with no pool in place (From: Tron Thomas <email@hidden>)
 >Re: NSCFArray autoreleased with no pool in place (From: Greg Parker <email@hidden>)
 >Re: NSCFArray autoreleased with no pool in place (From: Tron Thomas <email@hidden>)

  • Prev by Date: Re: Does -copyPath:toPath:handler run synchronously?
  • Next by Date: Re: Using an arraycontroller for different object classes
  • Previous by thread: Re: NSCFArray autoreleased with no pool in place
  • Next by thread: Fetch Requests on Non Standard Classes in Core Data
  • Index(es):
    • Date
    • Thread