Re: App works when launched from Xcode, not from Finder
Re: App works when launched from Xcode, not from Finder
- Subject: Re: App works when launched from Xcode, not from Finder
- From: Kai Brüning <email@hidden>
- Date: Fri, 18 Dec 2009 16:34:53 +0100
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 (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
>>
>
_______________________________________________
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