Closed
Bug 1131110
Opened 10 years ago
Closed 10 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)
Tracking
()
People
(Reporter: jmaher, Assigned: jmaher)
References
Details
(Keywords: intermittent-failure)
Attachments
(2 files)
1.24 KB,
patch
|
bholley
:
review+
|
Details | Diff | Splinter Review |
785 bytes,
patch
|
bholley
:
review+
|
Details | Diff | Splinter Review |
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.
Assignee | ||
Comment 1•10 years ago
|
||
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)
Assignee | ||
Comment 2•10 years ago
|
||
for reference: https://treeherder.mozilla.org/logviewer.html#?job_id=6409740&repo=mozilla-inbound
Updated•10 years ago
|
Keywords: intermittent-failure
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
Comment hidden (Legacy TBPL/Treeherder Robot) |
Comment hidden (Legacy TBPL/Treeherder Robot) |
Comment 5•10 years ago
|
||
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)
Updated•10 years ago
|
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
Comment 6•10 years ago
|
||
(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.
Comment hidden (Legacy TBPL/Treeherder Robot) |
Comment hidden (Legacy TBPL/Treeherder Robot) |
Comment hidden (Legacy TBPL/Treeherder Robot) |
Comment hidden (Legacy TBPL/Treeherder Robot) |
Comment hidden (Legacy TBPL/Treeherder Robot) |
Comment hidden (Legacy TBPL/Treeherder Robot) |
Comment hidden (Legacy TBPL/Treeherder Robot) |
Comment hidden (Legacy TBPL/Treeherder Robot) |
Comment hidden (Legacy TBPL/Treeherder Robot) |
Comment hidden (Legacy TBPL/Treeherder Robot) |
Comment hidden (Legacy TBPL/Treeherder Robot) |
Comment hidden (Legacy TBPL/Treeherder Robot) |
Comment hidden (Legacy TBPL/Treeherder Robot) |
Comment hidden (Legacy TBPL/Treeherder Robot) |
Comment hidden (Legacy TBPL/Treeherder Robot) |
Comment hidden (Legacy TBPL/Treeherder Robot) |
Comment hidden (Legacy TBPL/Treeherder Robot) |
Comment hidden (Legacy TBPL/Treeherder Robot) |
Comment hidden (Legacy TBPL/Treeherder Robot) |
Comment hidden (Legacy TBPL/Treeherder Robot) |
Comment hidden (Legacy TBPL/Treeherder Robot) |
Comment hidden (Legacy TBPL/Treeherder Robot) |
Comment hidden (Legacy TBPL/Treeherder Robot) |
Comment hidden (Legacy TBPL/Treeherder Robot) |
Comment hidden (Legacy TBPL/Treeherder Robot) |
Assignee | ||
Comment 32•10 years ago
|
||
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.
Assignee | ||
Comment 33•10 years ago
|
||
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.
Comment 34•10 years ago
|
||
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+
Assignee | ||
Comment 35•10 years ago
|
||
https://hg.mozilla.org/integration/mozilla-inbound/rev/2efeca47b3a7
https://hg.mozilla.org/mozilla-central/rev/2efeca47b3a7
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
status-firefox39:
--- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla39
Updated•10 years ago
|
Assignee | ||
Comment 37•10 years ago
|
||
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 → ---
Comment 38•10 years ago
|
||
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)
Assignee | ||
Comment 39•10 years ago
|
||
Attachment #8602638 -
Flags: review?(bobbyholley)
Updated•10 years ago
|
Attachment #8602638 -
Flags: review?(bobbyholley) → review+
Comment 41•10 years ago
|
||
https://hg.mozilla.org/mozilla-central/rev/ef8f4cfb27a4
Status: REOPENED → RESOLVED
Closed: 10 years ago → 10 years ago
status-firefox41:
--- → fixed
Resolution: --- → FIXED
Updated•10 years ago
|
status-firefox38.0.5:
--- → wontfix
status-firefox40:
--- → wontfix
status-firefox-esr38:
--- → wontfix
Target Milestone: mozilla39 → mozilla41
Comment hidden (Intermittent Failures Robot) |
You need to log in
before you can comment on or make changes to this bug.
Description
•