504563 - Mozmill command line application hangs if a restart test fails

Status: RESOLVED DUPLICATE of bug 519540

(Testing Graveyard :: Mozmill, defect, P1)

Description

[Henrik Skupin [:whimboo][⌚️UTC+2]]

While running Mozmill 1.2 against our current tests in the repository I have detected that the command line script gets stuck in an infinite loop when one of the tests fails.

As example just use the following command with Shiretoko/Firefox 3.5:
mozmill-restart -t firefox/restartTests/testExtensionInstallUninstall

The installation will fail because we cannot click the install button on AMO. The browser will be closed but the script hangs.

Canceling the script gives following traceback output:
Test Failed : testInstallExtension in /Volumes/data/projects/mozmill-tests/firefox/restartTests/testExtensionInstallUninstall/test1.js

^CTraceback (most recent call last):
  File "/usr/local/bin/mozmill-restart", line 8, in <module>
    load_entry_point('mozmill==1.2', 'console_scripts', 'mozmill-restart')()
  File "/Volumes/data/build/mozmill/trunk/mozmill/__init__.py", line 398, in restart_cli
    RestartCLI().run()
  File "/Volumes/data/build/mozmill/trunk/mozmill/__init__.py", line 385, in run
    super(RestartCLI, self).run(*args, **kwargs)
  File "/Volumes/data/build/mozmill/trunk/mozmill/__init__.py", line 358, in run
    self.options.report)
  File "/Volumes/data/build/mozmill/trunk/mozmill/__init__.py", line 293, in run_tests
    self.run_dir(d, report, sleeptime)
  File "/Volumes/data/build/mozmill/trunk/mozmill/__init__.py", line 262, in run_dir
    self.stop_runner()
  File "/Volumes/data/build/mozmill/trunk/mozmill/__init__.py", line 224, in stop_runner
    self.runner.wait(timeout=5)
  File "/Volumes/data/build/mozrunner/mozrunner/__init__.py", line 454, in wait
    self.process_handler.wait(timeout=timeout)
  File "/Volumes/data/build/mozrunner/mozrunner/killableprocess.py", line 238, in wait
    return group_wait()
  File "/Volumes/data/build/mozrunner/mozrunner/killableprocess.py", line 220, in group_wait
    time.sleep(.5); count += .5

Comment 1

[Henrik Skupin [:whimboo][⌚️UTC+2]]

This should also be fixed along with bug 504440. Setting to P1.

Comment 2

[Jeff Hammel]

Is this still an issue?

Comment 3

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Yes, it's still an issue. Just open the above mentioned test (comment 0) and replace the following line:

- "//div[@id='addon-summary']/div/div/div/p/a/span"
+ "//div[@id='addon-summary']/div/div/div/p/a/spa"

Running the test will close the browser but the back-end hangs. Jeff, we should add this as dependency for the build bot bug.

Comment 4

[Andrew Halberstadt [:ahal]]

Is this only reproducible in Firefox 3.5?  I can't reproduce in Fx 3.6 on Ubuntu (and the test doesn't work at all in Minefield due to the new addons manager) when doing:

- "//div[@id='addon-summary']/div/div/div/p/a/span"
+ "//div[@id='addon-summary']/div/div/div/p/a/spa"


In Fx 3.6 the test fails, closes and then the next test starts up.

Comment 5

[cmtalbert]

This seems like something that is only happening on incorrect tests and we have not been able to reproduce it at all.  Therefore, we are not taking this in 1.4.2.

Comment 6

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Sorry for the delay but I was on vacation. So by today I have some new information:

While running the update tests against 3.6.9pre builds today I notice the same problem. The update server is totally slow today and only serves updates with about 50kb/s. That means we run into a timeout. The result is that the test is marked as failed:

TEST-UNEXPECTED-FAIL | /var/folders/85/85YEzSCiEiyDDPnVLLhW3k+++TI/-Tmp-/tmpYPPV4_.mozmill-tests/firefox/softwareUpdate/testFallbackUpdate/test1.js | testFallbackUpdate_Download
TEST-START | /var/folders/85/85YEzSCiEiyDDPnVLLhW3k+++TI/-Tmp-/tmpYPPV4_.mozmill-tests/firefox/softwareUpdate/testFallbackUpdate/test1.js | teardownModule
TEST-PASS | /var/folders/85/85YEzSCiEiyDDPnVLLhW3k+++TI/-Tmp-/tmpYPPV4_.mozmill-tests/firefox/softwareUpdate/testFallbackUpdate/test1.js | teardownModule
*** gDownloadingPage
*** gDownloadingPage
*** gDownloadingPage

Firefox get closed but the script hangs and doesn't process with test2.js.

(In reply to comment #5)
> This seems like something that is only happening on incorrect tests and we have
> not been able to reproduce it at all.  Therefore, we are not taking this in
> 1.4.2.

Hm, what do you mean by incorrect tests? Our tests are correct and working. And by simply changing a lookup string doesn't make a test incorrect. The test will fail, that's correct but the CLI shouldn't freeze whatever happens in the test.

As far as I can imagine that only happens for restart tests with multiple test modules.

Comment 7

[Henrik Skupin [:whimboo][⌚️UTC+2]]

A restart of my machine solved this problem. But that reminds me again for bug 519540, which could have been the cause for this issue.