Closed Bug 1131110 Opened 7 years ago Closed 7 years ago

Intermittent OSX 10.6 run-by-dir test_bug484459.xul | uncaught exception - ReferenceError: x is not defined at chrome://mochitests/content/chrome/js/xpconnect/tests/chrome/test_bug484459.xul:30

Categories

(Core :: XPConnect, defect)

All
macOS
defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla41
Tracking Status
firefox37 --- wontfix
firefox38 --- wontfix
firefox38.0.5 --- wontfix
firefox39 --- wontfix
firefox40 --- wontfix
firefox41 --- fixed
firefox-esr31 --- wontfix
firefox-esr38 --- wontfix

People

(Reporter: jmaher, Assigned: jmaher)

References

Details

(Keywords: intermittent-failure)

Attachments

(2 files)

08:02:34 INFO - 2041 INFO TEST-START | js/xpconnect/tests/chrome/test_bug484459.xul
08:02:34 INFO - JavaScript warning: chrome://mochitests/content/chrome/js/xpconnect/tests/chrome/test_bug484459.xul, line 29: mutating the [[Prototype]] of an object will cause your code to run very slowly; instead create the object with the correct initial [[Prototype]] value using Object.create
08:02:34 INFO - 2042 INFO TEST-UNEXPECTED-FAIL | js/xpconnect/tests/chrome/test_bug484459.xul | uncaught exception - ReferenceError: x is not defined at chrome://mochitests/content/chrome/js/xpconnect/tests/chrome/test_bug484459.xul:30
08:02:34 INFO - JavaScript error: chrome://mochitests/content/chrome/js/xpconnect/tests/chrome/test_bug484459.xul, line 30: ReferenceError: x is not defined
08:02:34 INFO - 2043 INFO MEMORY STAT vsize after test: 3370897408
08:02:34 INFO - 2044 INFO MEMORY STAT residentFast after test: 275681280
08:02:34 INFO - 2045 INFO MEMORY STAT heapAllocated after test: 84915112
08:02:34 INFO - 2046 INFO TEST-OK | js/xpconnect/tests/chrome/test_bug484459.xul | took 45ms 

In looking at this bug, I see that it is intentionally written this way:
https://dxr.mozilla.org/mozilla-central/source/js/xpconnect/tests/chrome/test_bug484459.xul?from=test_bug484459.xul&case=true#1

What I am confused about is that this is showing up on OSX 10.6 only (saw a couple times in try runs, and now a few times since we landed bug 1110982).  We are obviously changing the timing of things by only running a smaller set of tests (this is now the 4th test to run after the browser starts up).

If there is a fix for this, I would like to see it in place, otherwise, we could disable this on osx 10.6 only (assuming I can figure out manifest syntax for 10.6, this might end up being disabled on "osx* opt" only).

lets at least spend a bit of time trying to understand this first.
bz, you had originally authored the fix and test (5.5 years ago), any thoughts here or thoughts on who might be able to help out?
Flags: needinfo?(bzbarsky)
Summary: test_bug484459.xul fails intermittently on osx 10.6 in run-by-dir mode with: ReferenceError: x is not defined → Intermittent test_bug484459.xul | uncaught exception - ReferenceError: x is not defined at chrome://mochitests/content/chrome/js/xpconnect/tests/chrome/test_bug484459.xul:30 on OSX 10.6 in run-by-dir mode
This is ... quite odd.  I mean, the evalInSandbox should be running after the iframe has loaded, at which point we better have had the "var x" run, no?

Worth doing some try runs that log the location.href and document.URL and document.readyState of "w" just to see whether we're for some reason running the function at some point before the iframe src has actually loaded...
Flags: needinfo?(bzbarsky)
Summary: Intermittent test_bug484459.xul | uncaught exception - ReferenceError: x is not defined at chrome://mochitests/content/chrome/js/xpconnect/tests/chrome/test_bug484459.xul:30 on OSX 10.6 in run-by-dir mode → Intermittent OSX 10.6 run-by-dir test_bug484459.xul | uncaught exception - ReferenceError: x is not defined at chrome://mochitests/content/chrome/js/xpconnect/tests/chrome/test_bug484459.xul:30
(In reply to Boris Zbarsky [:bz] from comment #5)
> This is ... quite odd.  I mean, the evalInSandbox should be running after
> the iframe has loaded, at which point we better have had the "var x" run, no?
> 
> Worth doing some try runs that log the location.href and document.URL and
> document.readyState of "w" just to see whether we're for some reason running
> the function at some point before the iframe src has actually loaded...

Yeah. It's also worth noting that doing sandbox.__proto__ is long-since deprecated (you're supposed to create the sandbox with the sandboxPrototype option). I still don't think that explains what's going on here though, since this is intermittent and 10.6-only.

This is probably a deeper underlying bug here, and might be causing other things to fail. Worth investigating a bit, though I wouldn't mind much if we need to turn off this test for osx 10.6.
Of course after putting in some SimpleTest.info() statements and running this 30 times on try yields no reproduction.

I will keep an eye on this as obviously it was a real problem and we have a series of other issues to resolve before making run-by-dir default for mochitest-chrome.
After many attempts at printing out what the url is, I ended up realizing that whenever I tried to debug this I would fix the problem.  I have a few try pushes with hundreds of runs combined where I do not see this problem anymore.  

I figured my patch is safe enough and in the scenario where we do fail in the future, this would yield more useful information.
Assignee: nobody → jmaher
Status: NEW → ASSIGNED
Attachment #8569812 - Flags: review?(bobbyholley)
Comment on attachment 8569812 [details] [diff] [review]
verify url and frame src (1.0)

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

::: js/xpconnect/tests/chrome/test_bug484459.xul
@@ +27,5 @@
>        var w = $('ifr').contentWindow.wrappedJSObject;
>        var sandbox = new Components.utils.Sandbox(w);
>        sandbox.__proto__ = w;
> +      SimpleTest.ok(location.href, url, "location.href is set properly");
> +      SimpleTest.ok(w.location, "data:text/html,<script>var%20x=3</script>", "contents of w.location are correct");

Any reason to use |SimpleTest.ok| here rather than just |ok|?

r=me either way.
Attachment #8569812 - Flags: review?(bobbyholley) → review+
https://hg.mozilla.org/mozilla-central/rev/2efeca47b3a7
Status: ASSIGNED → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla39
I am pushing on this again and I see this error on osx10.10 and winxp:
https://treeherder.mozilla.org/#/jobs?repo=try&revision=c12c99b8117c

odd, looking at the print messages I added we have the correct url and data value.  I am up for hacking on this a bit more or disabling it.

:bholley, any thoughts?
Status: RESOLVED → REOPENED
Flags: needinfo?(bobbyholley)
Resolution: FIXED → ---
I don't have the cycles to dig into it, and the test isn't testing anything very important. Let's just disable it.
Flags: needinfo?(bobbyholley)
Attachment #8602638 - Flags: review?(bobbyholley)
Attachment #8602638 - Flags: review?(bobbyholley) → review+
https://hg.mozilla.org/mozilla-central/rev/ef8f4cfb27a4
Status: REOPENED → RESOLVED
Closed: 7 years ago7 years ago
Resolution: --- → FIXED
Target Milestone: mozilla39 → mozilla41
See Also: → 1255284
You need to log in before you can comment on or make changes to this bug.