879491 - httpd.js failure causes "TypeError: can't access dead object" in windows.js while running test manifests

Status: RESOLVED WORKSFORME

(Testing Graveyard :: Mozmill, defect)

Description

[Szabolcs Hubai (:xabolcs)]

Attachment: testrun with commented in dumps in windows.js

From bug 865641 comment #3.
(In reply to Henrik Skupin (:whimboo) from comment #2)
> I could think of that this bug is related to our broken window
> initialization code as covered on bug 872237. Szabolcs, do you still see it
> with the proposed patch on the other bug applied?

Yes, I still see it with attachment 755849 [details] [diff] [review] [diff] [review] applied.
And if I run a manifest like 'mutt/mutt/tests/js/controller/tests.ini',
I got "TypeError: can't access dead object"! after the "fname" failure. :-/

> CRITICAL | Framework Failure | {
>  "message": "[JavaScript Error: \"TypeError: can't access dead object \" 
>  {file: \"resource://mozmill/modules/windows.js\" line: 188]"
> }


See bug 872237 comment #14:
> If I change |if (aWindow.content)| to |if (aWindow.document.readyState == "complete")| near L262, then I'm facing with bug 865641.



And from bug 872237 comment #43.
Comment on attachment 756084 [details] [diff] [review] [diff] [review]
Patch v1.1

Review of attachment 756084 [details] [diff] [review] [diff] [review]:
-----------------------------------------------------------------

Henrik, regarding to my comment in bug 865641 comment #3,
you should nuke the sleep statement out from
|DOMContentLoadedHandler| near L180 [1], IMHO.




[1]: https://github.com/mozilla/mozmill/blob/300232fcf34d/mozmill/mozmill/extension/resource/modules/windows.js#L180




Steps to reproduce:
1. get mozmill-env working with mozmill master [1]
2. apply r+-ed patch from bug 872237 [2]
3. mozmill -b ~/mozilla/apps/fxbeta/firefox -m mutt/mutt/tests/js/controller/tests.ini
4. Mozmill Framework Failure occurs after httpd.js related failure


See example (with dump enabled) output in attachment.

The dead object error doesn't occur, if mozmill runs only one test (i.e. using "-t").



[1]: currently https://github.com/mozilla/mozmill/commit/4677a09711f
[2]: currently attachment 756940 [details] [diff] [review]

Comment 1

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

Attachment: example patch

So the problem happens in line 191 of windows.js:

> if ("defaultView" in doc) {

That most likely happens because of a race condition here. In the DOMContentLoadedHandler we are waiting for about 1s before continuing. That means an error page has been triggered due to that we weren't able to load the local page. But somehow another load event has been triggered so we marked the page as being loaded before the DOMContentLoadedHandler has been finished. 

Szabolcs, can you please try out the attached example patch? Did it fix the problem for you? Please comment in all dump statements and attach the log again. Also keep in mind to run mozmill with --console-level=DEBUG.

Comment 2

[Szabolcs Hubai (:xabolcs)]

Comment on attachment 758377 [details] [diff] [review]
example patch

Review of attachment 758377 [details] [diff] [review]:
-----------------------------------------------------------------

Without patch applied I got:
CRITICAL | Framework Failure | {
  "message": "[JavaScript Error: \"TypeError: can't access dead object\" {file: \"resource://mozmill/modules/windows.js\" line: 191}]"
}

With patch applied I got no error like above!

I'll attach the requested detailed output soon.

Comment 3

[Szabolcs Hubai (:xabolcs)]

Attachment: testrun with applied patch + dumps + DEBUG loglevel

Here is the output from
$ mozmill -b ~/mozilla/apps/nightly/firefox -m mutt/mutt/tests/js/controller/tests.ini --console-level=DEBUG

Comment 4

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

Szabolcs, in which test did the failure occur before? I haven't seen or missed it that you mentioned it before.

Comment 5

[Szabolcs Hubai (:xabolcs)]

(In reply to Henrik Skupin (:whimboo) from comment #4)
> Szabolcs, in which test did the failure occur before? I haven't seen or
> missed it that you mentioned it before.

This is not specified to test case, just the httpd.js failure should be triggered somehow.
This exception is triggered by manifest run.
I reproduce it with the builtin mutt tests.

See description!
(In reply to Szabolcs Hubai (:xabolcs) from comment #0)
> <snip>
> And if I run a manifest like 'mutt/mutt/tests/js/controller/tests.ini',
> I got "TypeError: can't access dead object"! after the "fname" failure. :-/
> 
> <snip>
>
> Steps to reproduce:
> 1. get mozmill-env working with mozmill master [1]
> 2. apply r+-ed patch from bug 872237 [2]
> 3. mozmill -b ~/mozilla/apps/fxbeta/firefox -m
> mutt/mutt/tests/js/controller/tests.ini
> 4. Mozmill Framework Failure occurs after httpd.js related failure
> 
> 
> See example (with dump enabled) output in attachment.
> 

Please note this! :)
> The dead object error doesn't occur, if mozmill runs only one test (i.e.
> using "-t").


Of course, if no httpd.js error occurs, then there won't be any dead object error!

Comment 6

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

So a fix for bug 799557 might help then. Lets make it dependent. Strange is that i cannot see this issue.

Comment 7

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

Szabolcs, would you mind to test again? Has anything changed in the last couple of days?

Comment 8

[Szabolcs Hubai (:xabolcs)]

(In reply to Henrik Skupin (:whimboo) from comment #7)
> Szabolcs, would you mind to test again? Has anything changed in the last
> couple of days?

Hi!

Didn't played with Mozmill nowadays. Will try later tonight.
(Keeping needinfo.)

Comment 9

[Szabolcs Hubai (:xabolcs)]

Old revision (git: b6f02678eafe,
desc: Bug 874895 - Upgrade EventUtils to most recent version. r=hskupin) still failing with dead object.

Updating to master (git: c0277a214788, desc: Bug 865641 - Very first waitForPageLoad() can fail if the startup page takes too long to load. r=dhunt) eliminates the httpd.js problem, so this bug wouldn't trigger. :)

I'll try to find the fixing changeset later in the next days.

Comment 10

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

Good to hear. Thanks Szabolcs, I will wait then and concentrate on other open issues.

Comment 11

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

As for now I mark this as WFM. Feel free to add the dependency and mark it as fixed once we know which changeset fixed that. Thanks.