NSWorkspace launchApplicationAtURL:options:configuration:error cannot launch a app

  • I am using NSWorkspace launchApplicationAtURL:options:configuration:error
    launch the same app in Sandbox, sometimes there is an error:

    "The operation couldn't be completed. (OSStatus error - 10810)"

    this error appears occasionally not all the time. Is anybody know what's
    going on? Am I missing something?

    and in Mac OS 10.7.4 and 10.7.5 when I set a dictionary to the third
    parameter:

    [image: Inline image 1]

    but in new app's main function, argv array don't have
    "checkAccountArgument" parameter.

    in Mac OS 10.8.5 it seems OK.
    --
    Best Regards, strongxu
  • On 1 May 2013, at 10:29 PM, Zhuang Xu <strongxu...> wrote:

    > I am using NSWorkspace launchApplicationAtURL:options:configuration:error
    > launch the same app in Sandbox, sometimes there is an error:
    >
    > "The operation couldn't be completed. (OSStatus error - 10810)"
    >
    > this error appears occasionally not all the time. Is anybody know what's
    > going on? Am I missing something?

    You don't say whether the method actually fails.

    The code sample you attach does not capture the result of the launchApplication… method. I am guessing that you don't use the result, but are relying on the NSError object returned by reference.

    This is a mistake. By convention (I hear one or two Cocoa methods are exceptions), methods that take NSError-reference arguments are free to set an error object even if no error occurred. Many methods nil-out the referenced error pointer, but they don't have to. The returned error object is valid only if the principal return value of the method indicates failure (usually nil).

    Capture the return value, check for nil, and only then examine the error object.

    > and in Mac OS 10.7.4 and 10.7.5 when I set a dictionary to the third
    > parameter:
    >
    > [image: Inline image 1]
    >
    > but in new app's main function, argv array don't have
    > "checkAccountArgument" parameter.
    >
    > in Mac OS 10.8.5 it seems OK.

    I'm sure this isn't your problem, but does the URL in the first argument in the method point to an .app bundle? I would not expect the method to work reliably with a bare UNIX tool.

    — F

    --
    Fritz Anderson
    Xcode 4 Unleashed: 4.5 supplement for free!
    http://www.informit.com/store/xcode-4-unleashed-9780672333279
  • On Mac Developer Library, launchApplicationAtRL return value, I Quote"The
    the application could not be launched nil is returned, and the error is
    specified in *error*." and the problem is when get an error, the program
    can't launch an new application, and the error is not always appear.
    So I am guessing, either the arguments i set was not correct, or this
    method have some bugs in sandbox environment?

    On Fri, May 10, 2013 at 7:58 PM, Fritz Anderson <fritza...>wrote:

    > On 1 May 2013, at 10:29 PM, Zhuang Xu <strongxu...> wrote:
    >
    >> I am using NSWorkspace launchApplicationAtURL:options:configuration:error
    >> launch the same app in Sandbox, sometimes there is an error:
    >>
    >> "The operation couldn't be completed. (OSStatus error - 10810)"
    >>
    >> this error appears occasionally not all the time. Is anybody know what's
    >> going on? Am I missing something?
    >
    > You don't say whether the method actually fails.
    >
    > The code sample you attach does not capture the result of the
    > launchApplication… method. I am guessing that you don't use the result, but
    > are relying on the NSError object returned by reference.
    >
    > This is a mistake. By convention (I hear one or two Cocoa methods are
    > exceptions), methods that take NSError-reference arguments are free to set
    > an error object even if no error occurred. Many methods nil-out the
    > referenced error pointer, but they don't have to. The returned error object
    > is valid only if the principal return value of the method indicates failure
    > (usually nil).
    >
    > Capture the return value, check for nil, and only then examine the error
    > object.
    >
    >
    >> and in Mac OS 10.7.4 and 10.7.5 when I set a dictionary to the third
    >> parameter:
    >>
    >> [image: Inline image 1]
    >>
    >> but in new app's main function, argv array don't have
    >> "checkAccountArgument" parameter.
    >>
    >> in Mac OS 10.8.5 it seems OK.
    >
    > I'm sure this isn't your problem, but does the URL in the first argument
    > in the method point to an .app bundle? I would not expect the method to
    > work reliably with a bare UNIX tool.
    >
    > — F
    >
    > --
    > Fritz Anderson
    > Xcode 4 Unleashed: 4.5 supplement for free!
    > http://www.informit.com/store/xcode-4-unleashed-9780672333279
    >
    >

    --
    Best Regards, strongxu
  • On May 1, 2013, at 11:29 PM, Zhuang Xu <strongxu...> wrote:
    > I am using NSWorkspace launchApplicationAtURL:options:configuration:error
    > launch the same app in Sandbox, sometimes there is an error:
    >
    > "The operation couldn't be completed. (OSStatus error - 10810)"

    What do you mean "there is an error"? Does the above message appear in the console? Do you get an alert?

    > this error appears occasionally not all the time. Is anybody know what's
    > going on? Am I missing something?

    I found this:

    <http://www.thexlab.com/faqs/error-10810.html>
    "One cause of this error is that the Mac® OS X process table is full."

    I haven't read the whole article, but it suggests that either your app or some other app is filling up the process table. It does say "One cause", not "The only cause", so it's possible you have a different problem, but this is the first thing I'd check.

    You don't mention whether you tried Google. I did but got lucky. The first thing I searched for was "OSStatus error - 10810" (without the quotes) and the above link was the first result. If I had Googled for the whole message "The operation couldn't be completed. (OSStatus error - 10810)", the results would have been less useful.

    When I Googled for "10810 site:developer.apple.com" (or searched for "10810" in the documentation, using Xcode) I only found the Launch Services Reference, which only told me the error means "An unknown error has occurred."

    <https://developer.apple.com/library/mac/#documentation/Carbon/Reference/Lau
    nchServicesReference/Reference/reference.html
    >

    This is consistent with a full process table being one possible cause, not the only one. But it's the first thing I would check for.

    > and in Mac OS 10.7.4 and 10.7.5 when I set a dictionary to the third
    > parameter:
    >
    > [image: Inline image 1]

    It's good that you showed your code, but you know, you don't have to take a screen shot. You can just paste the actual code into email. :) Easier for you and easier for us, because we may want to show how to fix your code. If I want to do that I have to type the code myself, reading from your screen shot, instead of just copying it.

    > but in new app's main function, argv array don't have
    > "checkAccountArgument" parameter.

    How do you know this? The docs for NSWorkspaceLaunchConfigurationArguments say "Ignored if a new instance of the application is not launched." So maybe the app isn't getting launched.

    > in Mac OS 10.8.5 it seems OK.

    I ran the command "ulimit -a", which I got from the article I found. On a 10.6.8 system it shows 266 as the max user processes, which matches what the article says. However on a 10.8.3 system it shows 709. This might explain why you don't run into the problem on 10.8.x.

    --Andy
  • On May 10, 2013, at 10:50 PM, Zhuang Xu <strongxu...> wrote:
    > On Mac Developer Library, launchApplicationAtRL return value, I Quote"The
    > the application could not be launched nil is returned, and the error is
    > specified in *error*." and the problem is when get an error, the program
    > can't launch an new application, and the error is not always appear.

    I can't tell if you understood Fritz's suggestion.

    The documentation you are quoting says that the return value of launchApplicationAtURL:options:configuration:error: is either an instance of NSRunningApplication or nil. Fritz is saying the proper way for your code to check for an error is something like:

    NSArray *arguments = [NSArray arrayWithObject:@"checkAccountArgument"];

    NSError *error = nil;
    NSRunningApplication *app = [[NSWorkspace sharedWorkspace] launchApplicationAtURL: url options: options configuration: [NSDictionary dictionaryWithObject:arguments forKey:NSWorkspaceLaunchConfigurationArguments] error: &error];

    if (app == nil)
    {
        NSLog(@"Do something here about the error %@", error);
    }

    What happens if you do this? The NSError might simply say something about -10810, with no more information than you already have. But maybe it will say something more specific, for example about the process table.

    (And again, it was rather inconvenient for me to type the above code, and hope I did not make a typo. Next time please just paste the code instead of a screen shot. Less effort, less bandwidth, more likelihood someone will take the trouble to show corrections to the code.)

    --Andy
  • I'm pretty sure there are restrictions on passing arguments into an
    application if you are launching it from a sandboxed app.

    I believe the specific topic of passing arguments was covered in one of the
    WWDC videos on app sandboxing in 2012 (might have been WWDC 2011).
    Unfortunately, sandboxing behavior has changed since it was introduced. And
    there are inconsistencies between the versions of the OS, which can make
    sandboxing & supporting older versions of OS X tricky.

    Mark

    On Fri, May 10, 2013 at 11:54 PM, Andy Lee <aglee...> wrote:

    > On May 10, 2013, at 10:50 PM, Zhuang Xu <strongxu...> wrote:
    >> On Mac Developer Library, launchApplicationAtRL return value, I Quote"The
    >> the application could not be launched nil is returned, and the error is
    >> specified in *error*." and the problem is when get an error, the program
    >> can't launch an new application, and the error is not always appear.
    >
    > I can't tell if you understood Fritz's suggestion.
    >
    > The documentation you are quoting says that the return value of
    > launchApplicationAtURL:options:configuration:error: is either an instance
    > of NSRunningApplication or nil. Fritz is saying the proper way for your
    > code to check for an error is something like:
    >
    > NSArray *arguments = [NSArray arrayWithObject:@"checkAccountArgument"];
    >
    > NSError *error = nil;
    > NSRunningApplication *app = [[NSWorkspace sharedWorkspace]
    > launchApplicationAtURL: url options: options configuration: [NSDictionary
    > dictionaryWithObject:arguments
    > forKey:NSWorkspaceLaunchConfigurationArguments] error: &error];
    >
    > if (app == nil)
    > {
    > NSLog(@"Do something here about the error %@", error);
    > }
    >
    > What happens if you do this? The NSError might simply say something about
    > -10810, with no more information than you already have. But maybe it will
    > say something more specific, for example about the process table.
    >
    > (And again, it was rather inconvenient for me to type the above code, and
    > hope I did not make a typo. Next time please just paste the code instead of
    > a screen shot. Less effort, less bandwidth, more likelihood someone will
    > take the trouble to show corrections to the code.)
    >
    > --Andy
    >

    --
    Mark Munz
    unmarked software
    http://www.unmarked.com/
previous month may 2013 next month
MTWTFSS
    1 2 3 4 5
6 7 8 9 10 11 12
13 14 15 16 17 18 19
20 21 22 23 24 25 26
27 28 29 30 31    
Go to today