On Fri, May 15, 2009 at 11:00 PM, Tron Thomas <[email protected]> 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 protected]) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [email protected]
