566575 - Some tests FAIL on first run and PASS or hang on subsequent runs

Status: RESOLVED FIXED

(Firefox :: Sync, defect)

Description

[Philipp von Weitershausen [:philikon]]

Using Firefox 3.6 or a nightly trunk build as XULRUNNER_BIN, some tests FAIL the first time they're run and either PASS or (as it is on my machine) hang on subsequent test runs. Changing XULRUNNER_BIN to point to a different version of Firefox seems to reset the test run count "observable".

These tests FAIL for the first run and hang on subsequent runs:

* test_auth_manager
* test_records_crypto
* test_records_keys
* test_records_wbo
* test_resource

These tests FAIL for the first run and PASS on subsequent runs:

* test_tracker_addChanged
* test_utils_catch
* test_utils_deepEquals
* test_utils_deferGetSet
* test_utils_lock
* test_utils_makeGUID
* test_utils_notify

None of this occurs when using Firefox 3.5.9 as XULRUNNER_BIN.

Comment 1

[Ed Lee :Mardak]

(In reply to comment #0)
> * test_auth_manager
> * test_records_crypto
> * test_records_keys
> * test_records_wbo
> * test_resource
Are these the ones that generate a keypair and just take a longer time to run?

Comment 2

[Philipp von Weitershausen [:philikon]]

(In reply to comment #1)
> Are these the ones that generate a keypair and just take a longer time to run?

Of those only test_records_crypto generates a keypair. test_crypto_keypair actually passes just fine every time. And of course all tests pass with Firefox 3.5.9. So I don't think that's it.

Comment 3

[Philipp von Weitershausen [:philikon]]

Ok, after a reboot all mentioned tests also FAIL with Firefox 3.5.9 on the first run (and PASS on subsequent runs). Weird.

Poking into this some more, it seems that something with the module imports doesn't seem to work for the first test run. The test output logs always show one of the following exceptions:

  ReferenceError: Log4Moz is not defined
  ReferenceError: Tracker is not defined
  ReferenceError: Utils is not defined

(and if not then it's because the whole test code is wrapped in a try-finally clause so usually the finally part fails)

Comment 4

[Philipp von Weitershausen [:philikon]]

I should learn how to read the whole log. These exceptions occur before the ReferenceErrors:

[Exception... "Component returned failure code: 0x80040111 (NS_ERROR_NOT_AVAILABLE) [nsIXPCComponents_Utils.import]"  nsresult: "0x80040111 (NS_ERROR_NOT_AVAILABLE)"  location: "JS frame :: chrome://harness/content/main.js -> file:///Users/philipp/dev/mozilla/weave/weave/tests/unit/head.js :: <TOP_LEVEL> :: line 352"  data: no]
[Exception... "Component returned failure code: 0x80040111 (NS_ERROR_NOT_AVAILABLE) [nsIXPCComponents_Utils.import]"  nsresult: "0x80040111 (NS_ERROR_NOT_AVAILABLE)"  location: "JS frame :: chrome://harness/content/main.js -> file:///Users/philipp/dev/mozilla/weave/weave/tests/unit/test_auth_manager.js :: <TOP_LEVEL> :: line 1"  data: no]

In other words, Cu.import(PATH) fails because it can't find PATH. This looks a lot like Bug 546628.

Comment 5

[Philipp von Weitershausen [:philikon]]

Indeed it's choking on importing anything from resource:///weave. Deleting extensions.ini in the test profile will provoke this issue, so it looks like we're racing add-on setup. This also explains the rather random occurrence (sometimes it happens with a certain version of Firefox, sometimes it doesn't).

The hanging problems is due to httpd.js (e.g. Bug 521189). Will round up a patch to update httpd.js to the latest version from mozilla-central.

Comment 6

[Philipp von Weitershausen [:philikon]]

Attachment: Update httpd.js from mozilla-central

httpd.js from mozilla-central. server.stop() now expects a callback parameter, so pass a no-op where it's used.

Comment 7

[Ed Lee :Mardak]

http://hg.mozilla.org/labs/weave/rev/b38ad239b4f1
Update to httpd.js from mozilla-central. server.stop() now expects a callback parameter, so pass a no-op where it's used.

Comment 8

[Ed Lee :Mardak]

http://hg.mozilla.org/labs/weave/rev/d212b186b22f (new url from hg magic)
Update to httpd.js from mozilla-central. server.stop() now expects a callback parameter, so pass a no-op where it's used.