Re: -[NSSharedWorkspace openFile:]: Application exits with status 255
Re: -[NSSharedWorkspace openFile:]: Application exits with status 255
- Subject: Re: -[NSSharedWorkspace openFile:]: Application exits with status 255
- From: Jeff Johnson <email@hidden>
- Date: Thu, 23 Apr 2009 15:11:06 -0500
This reminds me very much of a problem I've had with a helper
application executable in the main application's MacOS directory. In
Activity Monitor, the main application's name is given as the process
name of the helper application, rather than the helper application's
own name.
From what we've been able to determine, the problem may be a bug in
CFBundle. See the source here:
http://www.opensource.apple.com/darwinsource/10.5.6/CF-476.17/CFBundle.c
In the function _CFBundleGetMainBundleAlreadyLocked() there's a
comment, "//??? what if we are not the main executable in the bundle?"
Indeed, what if? Then we get the wrong result, of course!
Is your helper an actual application? That is, does it call
NSApplication methods? If so, then it really ought to be in its
own .app bundle, regardless of whether you put Helper.app in "Main.app/
Contents/MacOS" or "Main.app/Contents/Resources". I think that putting
the helper application executable in its own bundle, with it's own
Info.plist, etc., may solve the problem in any case. Having an
application that's not in an .app bundle is, as they say, 'undefined
behavior'.
-Jeff
On Apr 23, 2009, at 10:34 AM, Sidney San Martín wrote:
Thanks, Michael. I just figured out what was going on, and you're
absolutely right.
My helper's name is alphabetically before the main executable.
LaunchServices was choosing it to be launched as my application, and
the exit code (I should have realized) was the helper not
understanding the arguments passed to it by launchd.
What's perplexing is that LaunchServices clearly knew about the
CFBundleIdentifier, since it is included in the log message, but
didn't pick up on CFBundleExecutable. Could the helper's shared
instance of NSWorkspace not be affected by the new copy of the
application appearing or by the call to LSRegisterURL()? I'll try to
reduce it to a test project and file a radar...
The helper has been moved to Resources and all is working.
-Sidney
On Wed, Apr 22, 2009 at 11:12 PM, Michael Ash
<email@hidden> wrote:
On Wed, Apr 22, 2009 at 7:28 PM, Sidney San Martín <email@hidden>
wrote:
I just discovered a new behavior that might be helpful. I'm
storing my
helper in MacOS (so that it can be located with [NSBundle
pathForAuxiliaryExecutable:]). The call to openFile: causes both my
application and helper to be executed. My application exits (or so
launchd says, even if I put an NSLog in main(), nothing is printed),
but my helper runs successfully.
I suggest moving your helper out of MacOS. LaunchServices has various
bugs which get exposed when you do that. You'll probably have better
luck putting it in Resources or some other location.
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