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: PCWiz <email@hidden>
- Date: Fri, 18 Dec 2009 07:54:17 -0700
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? I am positive that I'm not directly using NSRecursiveLock or NSLock anywhere in my project.
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