669791 - Mac 10.5 opt test run reports cuddlefish.runner.CalledProcessError

Status: RESOLVED DUPLICATE of bug 671368

(Add-on SDK Graveyard :: General, defect, P1)

Description

[Myk Melez [:myk] [@mykmelez]]

I updated the version of the Add-on SDK tests run on the central branch this afternoon to address bug 669460 <http://tbpl.mozilla.org/?tree=Firefox&noignore=1&rev=ea752bcac5c5>, after which a Mac 10.5 opt test run reported a cuddlefish.runner.CalledProcessError failure:

http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1309986658.1309986913.26579.gz
  

  Using binary at '/Users/cltbld/talos-slave/test/build/Nightly.app/Contents/MacOS/firefox-bin'.
  dyld: unknown required load command 0x80000022
  Traceback (most recent call last):
    File "bin/cfx", line 29, in <module>
      cuddlefish.run()
    File "/Users/cltbld/talos-slave/test/build/addon-sdk-19b2d58d7fa6/python-lib/cuddlefish/__init__.py", line 487, in run
      test_all(env_root, defaults=options.__dict__)
    File "/Users/cltbld/talos-slave/test/build/addon-sdk-19b2d58d7fa6/python-lib/cuddlefish/__init__.py", line 311, in test_all
      test_all_examples(env_root, defaults)
    File "/Users/cltbld/talos-slave/test/build/addon-sdk-19b2d58d7fa6/python-lib/cuddlefish/__init__.py", line 355, in test_all_examples
      env_root=env_root)
    File "/Users/cltbld/talos-slave/test/build/addon-sdk-19b2d58d7fa6/python-lib/cuddlefish/__init__.py", line 783, in run
      norun=options.no_run)
    File "/Users/cltbld/talos-slave/test/build/addon-sdk-19b2d58d7fa6/python-lib/cuddlefish/runner.py", 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/runner.py", line 75, in check_output
      raise CalledProcessError(retcode, cmd, output=output)
  cuddlefish.runner.CalledProcessError: Command '['/Users/cltbld/talos-slave/test/build/Nightly.app/Contents/MacOS/firefox-bin', '-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

[Phil Ringnalda (:philor)]

http://asqueella.blogspot.com/2010/12/dyld-unknown-required-load-command.html and bug 602049, so, um, whoever it is calling firefox-bin there will probably want to call with arch -i386 on 10.5.

Comment 3

[Brian Warner [:warner :bwarner]]

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 runner.py 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 run_jetpack.py
 * we might be able to trick runner.py 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 run_jetpack.py 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

[Myk Melez [:myk] [@mykmelez]]

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 run_jetpack.py.

Comment 5

[Brian Warner [:warner :bwarner]]

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 host-6-48.mv.mozilla.com 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

[Brian Warner [:warner :bwarner]]

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.