574122 - tests hang when doing "cfx testall" or "cfx testall -a firefox"

Status: RESOLVED DUPLICATE of bug 578842

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

Description

[Ayan Shah[:ashah]]

Attachment: log

Downloaded the jetpack-sdk-latest.zip and ran both the following commands - 

cfx testall
cfx testall -a firefox. 

But the tests hang after a point. 
See log attached.

Firefox - Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.3) Gecko/20100401 Firefox/3.6.3

OS X - 10.6.1

Comment 1

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

Ayan: can you reproduce with the 0.5rc3 build?

https://ftp.mozilla.org/pub/mozilla.org/labs/jetpack/jetpack-sdk-0.5rc3.zip

Comment 2

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

Ayan: also, just to double check, are you testing against a Firefox 3.6.3 build or a trunk build?

My initial thought about this hang is that it is due to a minVersion/maxVersion conflict, since I saw a similar hang when testing against Firefox trunk builds after their version changed from 3.7a5pre to 3.7a6pre.

The hang was "fixed" by bumping the maxVersion for Firefox in python-lib/cuddlefish/app-extension/install.rdf over in changeset https://hg.mozilla.org/labs/jetpack-sdk/rev/4cd03ad96e46.  But that's more a temporary workaround than an actual fix, and it is going to break again the next time the version is bumped for trunk builds.  We need a more permanent fix.

Of course, if you're testing against a Firefox 3.6.3 build, then that's not the problem you're experiencing.

Comment 3

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

Atul: if this is what I think it is, you worked around it over in changeset https://hg.mozilla.org/labs/jetpack-sdk/rev/4cd03ad96e46, but we should figure out a more permanent fix that doesn't require us to keep reactively bumping the maxVersion in a static file.

Perhaps install.rdf could be generated dynamically and acquire a maxVersion equal to the output of --version for the binary in question (so users can test against any binary without it potentially hanging if it isn't explicitly labeled in advance as being supported)?

Comment 4

[Ayan Shah[:ashah]]

Myk: the tests still hang for me on 0.5rc3. I am using Firefox 3.6.3.

And when I try to get out of the hang by doing ctrl+z , i get the following:

Testing reading-data...
.info: My ID is 6724fc1b-3ec4-40e2-8583-8061088b3185
..
Malloc bytes allocated (in use by application): 17233984
Malloc bytes mapped (not necessarily committed): 30756864
Malloc bytes committed (r/w) in default zone: 17234752
Malloc bytes allocated (in use) in default zone: 27611136
Tracked memory objects in testing sandbox: 2

3 of 3 tests passed.
OK
^CTraceback (most recent call last):
  File "/Users/moco/Desktop/jetpack-sdk-0.5/bin/cfx", line 6, in <module>
    cuddlefish.run()
  File "/Users/moco/Desktop/jetpack-sdk-0.5/python-lib/cuddlefish/__init__.py", line 318, in run
    test_all(env_root, defaults=options.__dict__)
  File "/Users/moco/Desktop/jetpack-sdk-0.5/python-lib/cuddlefish/__init__.py", line 195, in test_all
    test_all_examples(env_root, defaults)
  File "/Users/moco/Desktop/jetpack-sdk-0.5/python-lib/cuddlefish/__init__.py", line 227, in test_all_examples
    env_root=env_root)
  File "/Users/moco/Desktop/jetpack-sdk-0.5/python-lib/cuddlefish/__init__.py", line 571, in run
    logfile=options.logfile)
  File "/Users/moco/Desktop/jetpack-sdk-0.5/python-lib/cuddlefish/runner.py", line 313, in run_app
    runner.wait(10)
  File "build/bdist.macosx-10.3-fat/egg/mozrunner/__init__.py", line 414, in wait
  File "build/bdist.macosx-10.3-fat/egg/mozrunner/killableprocess.py", line 239, in wait
  File "build/bdist.macosx-10.3-fat/egg/mozrunner/killableprocess.py", line 224, in group_wait
KeyboardInterrupt

Comment 5

[Drew Willcoxon :adw]

(In reply to comment #4)
>   File "build/bdist.macosx-10.3-fat/egg/mozrunner/__init__.py", line 414, in
> wait
>   File "build/bdist.macosx-10.3-fat/egg/mozrunner/killableprocess.py", line
> 239, in wait
>   File "build/bdist.macosx-10.3-fat/egg/mozrunner/killableprocess.py", line
> 224, in group_wait
> KeyboardInterrupt

It looks like cfx is using a different mozrunner than the one that comes with Jetpack.  I don't know enough about Python to say how to prevent that from happening, but I think it has something to do with fixing up your PYTHONPATH.

Comment 6

[Drew Willcoxon :adw]

See also bug 556562 comment 2.

Comment 7

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

Ayan: unless it's absolutely essential to keep the other version(s) of Mozrunner installed on your system, would it be possible to try uninstalling it/them and then running the tests again?  You could always reinstall afterwards.

I think Drew is probably right about this being an issue with multiple instances of Mozrunner installed on your system.  I don't know the solution, but testing without the additional instance(s) to confirm the etiology of the problem would be a good next step.

Comment 8

[Atul Varma [:atul]]

(In reply to comment #3)
> Atul: if this is what I think it is, you worked around it over in changeset
> https://hg.mozilla.org/labs/jetpack-sdk/rev/4cd03ad96e46, but we should figure
> out a more permanent fix that doesn't require us to keep reactively bumping the
> maxVersion in a static file.
> 
> Perhaps install.rdf could be generated dynamically and acquire a maxVersion
> equal to the output of --version for the binary in question (so users can test
> against any binary without it potentially hanging if it isn't explicitly
> labeled in advance as being supported)?

That's possible, though I really don't want to slow down the "startup" time of cfx any more than it already is... Another option, as I mention in another bug which I can't remember the number of right now, is to pull a machine-readable listing of all valid Firefox/Thunderbird/Gecko versions at "cfx testall" time and raise an error if they're not what they should be. An advantage of doing it this way is that it forces/encourage a human to actually verify that the tests work on those latest versions rather than blindly updating the numbers, which I assume is the reason maxVersion requires a real version to be specified (as opposed to e.g. putting "4.*" in it, which is what I'm sometimes tempted to do).

Comment 10

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

The Add-on SDK is no longer a Mozilla Labs experiment and has become a big enough project to warrant its own Bugzilla product, so the "Add-on SDK" product has been created for it, and I am moving its bugs to that product.

To filter bugmail related to this change, filter on the word "looptid".