Closed Bug 916004 Opened 6 years ago Closed 4 years ago

Intermittent test_bug330010.xul | uncaught exception - TypeError: generatedShape is undefined at chrome/test_bug330010.xul:16

Categories

(Core :: XUL, defect)

x86
macOS
defect
Not set
Points:
1

Tracking

()

RESOLVED FIXED
mozilla39
Tracking Status
firefox37 --- wontfix
firefox38 --- fixed
firefox39 --- fixed
firefox48 --- fixed
firefox49 --- fixed
firefox-esr31 --- wontfix
firefox-esr45 --- fixed
b2g-v2.2 --- fixed
b2g-master --- fixed

People

(Reporter: cbook, Unassigned)

References

()

Details

(Keywords: intermittent-failure)

Attachments

(1 file)

https://tbpl.mozilla.org/php/getParsedLog.php?id=27804238&tree=Mozilla-Inbound

Rev4 MacOSX Snow Leopard 10.6 mozilla-inbound opt test mochitest-other on 2013-09-12 18:52:26 PDT for push a84f8558ca61

slave: talos-r4-snow-047

18:55:05     INFO -  1572 ERROR TEST-UNEXPECTED-FAIL | chrome://mochitests/content/chrome/content/xul/templates/tests/chrome/test_bug330010.xul | uncaught exception - TypeError: generatedShape is undefined at chrome://mochitests/content/chrome/content/xul/templates/tests/chrome/test_bug330010.xul:16
18:55:05     INFO -  JavaScript error: chrome://mochitests/content/chrome/content/xul/templates/tests/chrome/test_bug330010.xul, line 16: generatedShape is undefined
Summary: Intermittent TEST-UNEXPECTED-FAIL | chrome://mochitests/content/chrome/content/xul/templates/tests/chrome/test_bug330010.xul | uncaught exception - TypeError: generatedShape is undefined at chrome/test_bug330010.xul:16 → Intermittent test_bug330010.xul | uncaught exception - TypeError: generatedShape is undefined at chrome/test_bug330010.xul:16
I checked in a possible fix which just preloads the datasource.

https://treeherder.mozilla.org/#/jobs?repo=mozilla-inbound&revision=8c45833b771a
https://hg.mozilla.org/mozilla-central/rev/8c45833b771a
Status: NEW → RESOLVED
Closed: 5 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
Target Milestone: --- → mozilla39
Assignee: nobody → enndeakin
Points: --- → 1
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Assignee: enndeakin → nobody
Neil, it seems like this has been getting steadily worse since mid-April.  Its now one of our top oranges.  Any thoughts?

https://brasstacks.mozilla.com/orangefactor/?display=Bug&bugid=916004&startday=2016-04-01&endday=2016-05-03&tree=trunk
Flags: needinfo?(enndeakin)
Don't have any other ideas. We should probably just disable this on Linux where is happens far more often.
Flags: needinfo?(enndeakin)
I managed to reproduce this in rr's chaos mode.  (--run-until-failure with large numbers didn't seem to help, but I hit it on the first iteration on my second try of chaos mode.)  So I have an rr recording of the failure now.
Attached file rr session
Here's a session in rr (without any reversing) that shows the basics of what's happening.  Basically:

 (1) we start an asynchronous load of the datasource
 (2) we call GetDataSourceBlocking, which I presume does a separate blocking load of the datasource
 (3) we then immediately expect the template to have been constructed, and call nsChildContentList::GetItem
 (4) the original load from (1) then completes.

How was this supposed to work?
Flags: needinfo?(enndeakin)
So we should probably just set the datasources attribute after the blocking load. I can look at this tomorrow.
Flags: needinfo?(enndeakin)
Flags: needinfo?(enndeakin)
https://hg.mozilla.org/integration/mozilla-inbound/rev/4fbc77b48fd9042cf94d09ec8c8c0ed2f9ab069d
Bug 916004, set datasource after loading to see if intermittent orange of test_bug330010.xul goes away
Flags: needinfo?(enndeakin)
I think it's clear at this point that the fix worked; it just needs to be merged around.
https://hg.mozilla.org/mozilla-central/rev/4fbc77b48fd9
Status: REOPENED → RESOLVED
Closed: 5 years ago4 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.