Closed Bug 1340441 Opened 5 years ago Closed 5 years ago

Intermittent file:///C:/slave/test/build/tests/reftest/tests/layout/base/crashtests/1338772-1.html | load failed: timed out waiting for reftest-wait to be removed

Categories

(Core :: Layout, defect)

defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla54
Tracking Status
firefox52 --- unaffected
firefox53 --- unaffected
firefox54 --- fixed

People

(Reporter: intermittent-bug-filer, Assigned: dholbert, NeedInfo)

References

Details

(Keywords: intermittent-failure, Whiteboard: [stockwell fixed])

It looks like this started failing intermittently as soon as it was added.

:dholbert - Can you make this test more reliable?
Flags: needinfo?(dholbert)
Blocks: 1338772
Sorry about that!

My first guess is that the onload event must be firing before we've done layout (which is allowed to happen) -- so we make the size-tweak before the first layout ever happens, which means the size-tweak doesn't count as a resize, which means we don't fire the resize handler & never clear "reftest-wait".

I'll adjust the test to use MozReftestInvalidate instead of an onload handler -- that should avoid this problem.
Assignee: nobody → dholbert
Pushed by dholbert@mozilla.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/ce729354cba0
Try to make crashtest 1338772-1.html more reliable. (no review, test-only)
(In reply to Daniel Holbert [:dholbert] from comment #5)
> I'll adjust the test to use MozReftestInvalidate instead of an onload
> handler -- that should avoid this problem.

Turns out this hypothetical-change wasn't good -- it neutered the crashtest such that it no longer triggered the ASAN abort, in pre-fixed builds!  So, there must be a semi-race-condition that we're depending on for the bad behavior here, and the MozReftestInvalidate fire-time is late enough that we "win" the race and don't trigger the crash.

So I made a slightly different tweak, which I think should still make the resize event fire reliably (and hence should get the "reftest-wait" attribute removed reliably). I verified this tweak still produces a crashy crashtest in pre-fixed builds. (I used the parent of the fix cset.)
Flags: needinfo?(dholbert)
https://hg.mozilla.org/mozilla-central/rev/ce729354cba0
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla54
This appears to still be happening.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Flags: needinfo?(dholbert)
So there still seems to be a race condition here that makes the resize handler fail to get triggered, some fraction of the time. Not sure why.

I tried to capture the failure using rr on a local "linux64-qr" configuration (ac_add_options --enable-webrender) -- that's the linux configuration where this fails reliably, it seems.  But unfortunately, that build won't run under rr.  I filed bug 1343102 on that.

Rather than investing more time in investigating & crafting the perfect crashtest here, I'm just going to add a setTimeout() with a failsafe reftest-wait removal, to make us proceed after ~500ms if we happen to go that long without invoking the resize handler.
Pushed by dholbert@mozilla.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/e0565c2ea34c
part 2: Add a failsafe to remove "reftest-wait" in crashtest 1338772-1.html, after some time has elapsed. (test-only, no review)
https://hg.mozilla.org/mozilla-central/rev/e0565c2ea34c
Status: REOPENED → RESOLVED
Closed: 5 years ago5 years ago
Resolution: --- → FIXED
Whiteboard: [stockwell fixed]
You need to log in before you can comment on or make changes to this bug.