On 18.12.2009, at 15:54, PCWiz wrote: > Yeah I definitely need to squash this bug. But as Greg Parker said, > @synchronized (which I'm using) has nothing to do with NSRecursiveLock. And > the only other threading related classes I'm using are NSOperationQueue and > NSInvocationOperation. Would one of these classes use NSRecursiveLock?
Possibly in Leopard, but very unlikely under Snow Leopard: NSOperationQueue is now based on Grand Central. > I am positive that I'm not directly using NSRecursiveLock or NSLock anywhere > in my project. Have you tried to break on [NSRecursiveLock alloc]? Or on one of the init methods? Kai > > Independent Cocoa Developer, Macatomy Software > http://macatomy.com > > > On 2009-12-18, at 12:07 AM, Kai Brüning wrote: > >> Great you found this issue. >> >> But according to the log output, it seems that you do have a serious >> threading-related problem. I wouldn’t ignore this, it may raise its head any >> time in the future and bite you badly. >> >> Good luck >> Kai >> >> On 18.12.2009, at 03:26, PCWiz wrote: >> >>> Thanks, will do. >>> >>> And regarding Jeremy's note about the 2 libraries can't be loaded, those >>> are Input Manager plugins that have nothing to do with my app. >>> >>> But I'm happy to say that I eventually found the cause of my problem. One >>> of the frameworks I was using was compiled using "i386 ppc" set as the >>> architecture. Setting this to "Standard (32-bit/64-bit Universal)" and >>> recompiling the framework fixed it. Xcode seems to launch the app in 32 bit >>> mode whether its in Debug or Release (because I have the Active >>> Architecture set to i386). When launched from Finder, the app launches in >>> 64 bit mode, and since that framework was not compiled with the x86_64 >>> architecture it screwed up the app. >>> >>> Hope this helps anyone else that runs into this issue. >>> >>> Independent Cocoa Developer, Macatomy Software >>> http://macatomy.com >>> >>> >>> On 2009-12-17, at 9:55 AM, Jens Alfke wrote: >>> >>>> >>>> On Dec 16, 2009, at 10:04 PM, PCWiz wrote: >>>> >>>>> I'm not using NSLock or NSRecursiveLock directly. I'm using @synchronized >>>>> on an object that multiple threads acess, to allow only one thread to >>>>> access the object at a time. >>>> >>>> The fact that the description of the lock is "<NSRecursiveLock: 0x16c2340> >>>> '(null)'" makes me suspect that you're synchronizing on a nil pointer, >>>> i.e. that when you call >>>> @synchronized(foo) { ... } >>>> the value of foo is nil. I'm pretty sure that's illegal, and I would have >>>> thought it would throw an exception, but maybe not. Try putting a check >>>> above the block, something like >>>> NSAssert(foo!=nil, @"no foo"); >>>> >>>> —Jens >>> >>> _______________________________________________ >>> >>> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) >>> >>> 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/lists%40kai-bruening.de >>> >>> This email sent to li...@kai-bruening.de >> > _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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 arch...@mail-archive.com
