Closed Bug 832571 Opened 7 years ago Closed 7 years ago

Entirely too frequent Android crashtests/ownerdiscard.html | load failed: timed out waiting for reftest-wait to be removed

Categories

(Core :: General, defect)

ARM
Android
defect
Not set

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: philor, Unassigned)

References

Details

(Keywords: intermittent-failure)

Somebody's going down over this, we just don't know who yet. The current back edge of the retriggers is

https://tbpl.mozilla.org/php/getParsedLog.php?id=18945290&tree=Mozilla-Inbound
Android Tegra 250 mozilla-inbound opt test crashtest-3 on 2013-01-18 17:25:31 PST for push 072531a694bf
slave: tegra-170

REFTEST TEST-START | http://10.250.48.218:30170/tests/image/test/crashtests/ownerdiscard.html | 625 / 729 (85%)
REFTEST TEST-UNEXPECTED-FAIL | http://10.250.48.218:30170/tests/image/test/crashtests/ownerdiscard.html | load failed: timed out waiting for reftest-wait to be removed
REFTEST INFO | Saved log: START http://10.250.48.218:30170/tests/image/test/crashtests/ownerdiscard.html
REFTEST INFO | Saved log: [CONTENT] OnDocumentLoad triggering WaitForTestEnd
REFTEST INFO | Saved log: [CONTENT] WaitForTestEnd: Adding listeners
REFTEST INFO | Saved log: Initializing canvas snapshot
REFTEST INFO | Saved log: [CONTENT] MakeProgress: STATE_WAITING_TO_FIRE_INVALIDATE_EVENT
REFTEST INFO | Saved log: [CONTENT] MakeProgress: dispatching MozReftestInvalidate
REFTEST INFO | Saved log: [CONTENT] MakeProgress: STATE_WAITING_FOR_REFTEST_WAIT_REMOVAL
REFTEST INFO | Saved log: [CONTENT] MakeProgress: waiting for reftest-wait to be removed
Backed out the cause in https://hg.mozilla.org/integration/mozilla-inbound/rev/31fea3e0be16
Assignee: nobody → philringnalda
Blocks: 784591
https://hg.mozilla.org/mozilla-central/rev/31fea3e0be16
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Looking at the test DOMContentLoaded can be fired before the image is downloaded, and we remove the image from the document at that point. So there's no guarantee that we'll kick off a decode for the image, and hence no guarantee we'll get a discard.

Josh, is the discard an important part of the test? Can we use another condition to end the test?
The crash being tested occurred during discard, so yes, it's important.
Well there's no guarantee that the test as written will get a discard. What can we do to fix the test?
It may not be necessary to use DOMContentLoaded in place of a regular load event.
Using the load event we don't seem to hit imgRequestProxy::ChangeOwner with mCanceled == true, so I don't think we would be still testing that bug anymore.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
I've backed out bug 784591 again (which had landed earlier today).
Assignee: philringnalda → nobody
Resolving WFM keyword:intermittent-failure bugs last modified >3 months ago, whose whiteboard contains none of:
{random,disabled,marked,fuzzy,todo,fails,failing,annotated,time-bomb,leave open}

There will inevitably be some false positives; for that (and the bugspam) I apologise. Filter on orangewfm.
Status: REOPENED → RESOLVED
Closed: 7 years ago7 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.