Last Comment Bug 669791 - Mac 10.5 opt test run reports cuddlefish.runner.CalledProcessError
: Mac 10.5 opt test run reports cuddlefish.runner.CalledProcessError
Status: RESOLVED DUPLICATE of bug 671368
Product: Add-on SDK
Classification: Client Software
Component: General (show other bugs)
: unspecified
: x86 Mac OS X
P1 major (vote)
: 1.1
Assigned To: Brian Warner [:warner :bwarner]
: 668812 (view as bug list)
Depends on:
Blocks: 629263
  Show dependency treegraph
Reported: 2011-07-06 16:46 PDT by Myk Melez [:myk] [@mykmelez]
Modified: 2011-07-14 01:57 PDT (History)
4 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---


Description User image Myk Melez [:myk] [@mykmelez] 2011-07-06 16:46:39 PDT
I updated the version of the Add-on SDK tests run on the central branch this afternoon to address bug 669460 <>, after which a Mac 10.5 opt test run reported a cuddlefish.runner.CalledProcessError failure:

  Using binary at '/Users/cltbld/talos-slave/test/build/'.
  dyld: unknown required load command 0x80000022
  Traceback (most recent call last):
    File "bin/cfx", line 29, in <module>
    File "/Users/cltbld/talos-slave/test/build/addon-sdk-19b2d58d7fa6/python-lib/cuddlefish/", line 487, in run
      test_all(env_root, defaults=options.__dict__)
    File "/Users/cltbld/talos-slave/test/build/addon-sdk-19b2d58d7fa6/python-lib/cuddlefish/", line 311, in test_all
      test_all_examples(env_root, defaults)
    File "/Users/cltbld/talos-slave/test/build/addon-sdk-19b2d58d7fa6/python-lib/cuddlefish/", line 355, in test_all_examples
    File "/Users/cltbld/talos-slave/test/build/addon-sdk-19b2d58d7fa6/python-lib/cuddlefish/", line 783, in run
    File "/Users/cltbld/talos-slave/test/build/addon-sdk-19b2d58d7fa6/python-lib/cuddlefish/", line 322, in run_app
      version_output = check_output([runner.binary, "-v"])
    File "/Users/cltbld/talos-slave/test/build/addon-sdk-19b2d58d7fa6/python-lib/cuddlefish/", line 75, in check_output
      raise CalledProcessError(retcode, cmd, output=output)
  cuddlefish.runner.CalledProcessError: Command '['/Users/cltbld/talos-slave/test/build/', '-v']' returned non-zero exit status -5

It isn't clear whether this is a Release Engineering issue or an Add-on SDK one; filing it in the latter bucket for now.

Brian: can you take a look at this one?
Comment 1 User image Phil Ringnalda (:philor) 2011-07-06 17:11:00 PDT and bug 602049, so, um, whoever it is calling firefox-bin there will probably want to call with arch -i386 on 10.5.
Comment 2 User image Myk Melez [:myk] [@mykmelez] 2011-07-07 11:37:04 PDT
*** Bug 668812 has been marked as a duplicate of this bug. ***
Comment 3 User image Brian Warner [:warner :bwarner] 2011-07-07 15:28:49 PDT
I don't think this is an SDK issue. It looks like the firefox binary being executed is having internal problems, like a dynamic library built for a different OS, ABI, or word length.

If adding an "arch -i386" prefix is the only way around this, hmm, thne I can think of a couple of directions to try:

 * modify the SDK's to know how to add this prefix when on OS-X, maybe in response to some command-line flag. Then also get this flag into
 * we might be able to trick into accepting a "--binary" argument which really has "arch -i386" buried in it. Like maybe invoking "cfx testall" with -b "arch -i386 /PATH/TO/FIREFOX" (depends upon the 'cfx' argument parser and how it creates the final command-line argv list). We'd still need to modify to pass this funny-looking argument in, and only on OS-X.

But it'd feel more robust if whatever firefox binary we're using could do the right thing by itself.
Comment 4 User image Myk Melez [:myk] [@mykmelez] 2011-07-07 15:47:54 PDT
Per bug 602049, the Firefox binary is not going to change; and who knows if Mac OS X will ever change to resolve this problem; so it looks like we're going to have to implement a workaround in our codebase.

Where we call the binary, can we prepend "arch -i386" automagically if we're running on Mac OS X 10.5?  If we do this without a command-line flag, we won't have to modify
Comment 5 User image Brian Warner [:warner :bwarner] 2011-07-07 16:18:56 PDT
Hm, ok, I'll think about that. 1: how to detect we're on 10.5 and not 10.6 (and on OS-X in general, for that matter). 2: how to get a 10.5 box on which I can test this (all my macs are up-to-date). "uname -a" on my 10.6.8 box reports:

  Darwin 10.8.0 Darwin Kernel Version 10.8.0: Tue Jun  7 16:33:36 PDT 2011; root:xnu-1504.15.3~1/RELEASE_I386 i386 i386

Does anyone know what it reports on a 10.5 box? uname is not my favorite what-platform-are-we-on query, but I don't think python offers anything more sensitive to version-of-the-OS differences.
Comment 6 User image Brian Warner [:warner :bwarner] 2011-07-14 01:57:38 PDT
Looks like Drew just provided a patch in bug 671368: the underlying 10.5 problem was fixed in our copy of mozrunner several months ago, but the -v check wasn't using it. Closing this as a dup now that 671368 is resolved.

*** This bug has been marked as a duplicate of bug 671368 ***

Note You need to log in before you can comment on or make changes to this bug.