David Baron :dbaron: Assignee
	Description • 9 years ago

We're disabling test_deferred_start.html on Linux mochitest-e10s, because it's failing, probably as a result of enabling vsync compositor (on Linux) and omt animations on the same day.

(More in a sec; need the bug number now for the comment.)

	David Baron :dbaron: Assignee
	Comment 1 • 9 years ago

from #developers:

> [2015-04-01 21:27:58 -0700] <dbaron> really?  That test failure that **was actually fixed in the try run of the same patches** decided to come back?
> [2015-04-01 21:29:05 -0700] <birtles> dbaron: yeah, I just saw that...
> [2015-04-01 21:29:34 -0700] <philor> there's that perfectly good Mulet bug, though, not like it would be the first permaorange we've just merrily starred
> [2015-04-01 21:29:35 -0700] <birtles> I did two try runs with just that patch and that test didn't fail once
> [2015-04-01 21:30:54 -0700] <dbaron> birtles, let me see if anything else interesting landed between the base of my try run and my inbound push
> [2015-04-01 21:31:37 -0700] <philor> did you check whether the try pushes for no good reason had RELEASE_BUILD set?
> [2015-04-01 21:32:47 -0700] <dbaron> philor, I did a parallel try push that did show failures
> [2015-04-01 21:33:24 -0700] <dbaron> philor, also, it got better on the next push
> [2015-04-01 21:35:44 -0700] <pulsebot> Check-in: https://hg.mozilla.org/integration/mozilla-inbound/rev/0f1095c9567f - Mason Chang - Bug 1144317 - Enable vsync refresh driver on Windows. r=kats
> [2015-04-01 21:38:21 -0700] <dbaron> birtles, in the test that's failing, what makes us wait for stuff to get to the compositor thread?
> [2015-04-01 21:39:23 -0700] <birtles> dbaron: the wait on animation.ready
> [2015-04-01 21:40:31 -0700] <dbaron> birtles, that waits on sync'ing to the compositor thread?
> [2015-04-01 21:41:54 -0700] <birtles> dbaron: in effect--one refresh driver tick after calling EndTransaction on the layer transaction we resolve that promise
> [2015-04-01 21:42:05 -0700] <birtles> that test used to be flaky because there was a race where sometimes the animation transform wasn't applied on the shadow layer tree but bug 1113425 should have fixed that
> [2015-04-01 21:42:40 -0700] <dbaron> birtles, I'm somewhat inclined towards disabling that test on relevant platforms rather than backing out omta again
> [2015-04-01 21:43:33 -0700] <birtles> dbaron: fair enough--I spent a long time getting that test to pass reliably, but it's better to have OMTA on than that test :)
> [2015-04-01 21:43:48 -0700] <dbaron> birtles, also, it might be failing only on mochitest-e10s, which has the compositor in a different process
> [2015-04-01 21:44:05 -0700] <birtles> dbaron: but it passes reliably on B2G which has the compositor in a different process
> [2015-04-01 21:44:17 -0700] <dbaron> birtles, I'm not even sure we're getting correct mochitest results out of B2G
> [2015-04-01 21:44:29 -0700] <dbaron> birtles, can you explain why jwatt's changes or your changes that broke the mochitests elsewhere didn't break them on B2G?
> [2015-04-01 21:44:46 -0700] <birtles> dbaron: I was wondering that myself
> [2015-04-01 21:45:47 -0700] <birtles> dbaron: but some of them could be masked by additional layer transactions that might be triggered by additional UI events etc.
> [2015-04-01 21:46:00 -0700] <dbaron> philor, you don't happen to know how to tell from inside a mochitest that we're in mochitest-e10s?
> [2015-04-01 21:46:20 -0700] <philor> dbaron: sorry, nope
> [2015-04-01 21:46:29 -0700] <birtles> we've had that before with those OMTA tests, move the mouse and the test passes
> [2015-04-01 21:47:12 -0700] <birtles> dbaron: but yes, I think switching off that test again is reasonable
> [2015-04-01 21:48:50 -0700] <birtles> dbaron: assuming that it used to pass reliably (and we weren't just incredibly lucky before) it should be possible to bisect the regression and hopefully easier to fix this time around
> [2015-04-01 21:49:33 -0700] <dbaron> birtles, oh, one of the changes that landed since my try run is:
> [2015-04-01 21:49:38 -0700] <dbaron> changeset:   237046:806abeb59e8f
> [2015-04-01 21:49:38 -0700] <dbaron> user:        Mason Chang <mchang@mozilla.com>
> [2015-04-01 21:49:38 -0700] <dbaron> date:        Wed Apr 01 08:26:37 2015 -0700
> [2015-04-01 21:49:38 -0700] <dbaron> summary:     Bug 1149391 - Enable software vsync compositor on Linux. r=kats
> [2015-04-01 21:50:49 -0700] <birtles> dbaron: we've had trouble with that test + vsync + e10s + omta before
> [2015-04-01 21:51:08 -0700] <birtles> bug 1119981
> [2015-04-01 21:51:13 -0700] <birtles> but bug 1113425 should have fixed it
> [2015-04-01 21:52:38 -0700] <birtles> dbaron: I think we just disable that test... it's going to take a while to work out what's going wrong there
> [2015-04-01 21:52:47 -0700] <birtles> for e10s only
> [2015-04-01 21:53:24 -0700] <dbaron> birtles, I was hoping to just disable half of it (i.e., the second half), but I don't know how to do that, so I'm likely to just disable it in the manifest if that's ok
> [2015-04-01 21:53:33 -0700] <birtles> dbaron: yes, I think that's fine


The set of changes since the good try run was:
hg log -r 'ancestors(7b75233a273c) - ancestors(e5b72a8edb82)'

	David Baron :dbaron: Assignee
	Comment 2 • 9 years ago

Backed out in https://hg.mozilla.org/integration/mozilla-inbound/rev/bce1203ac470, although underlying problem still present.

	David Baron :dbaron: Assignee
	Comment 3 • 9 years ago

I relanded the disabling in https://hg.mozilla.org/integration/mozilla-inbound/rev/9002c68ad577

	David Baron :dbaron: Assignee
	Comment 4 • 9 years ago

And disabling relanded again in:
https://hg.mozilla.org/integration/mozilla-inbound/rev/76671894fe90

	David Baron :dbaron: Assignee
	Comment 5 • 9 years ago

needinfo as a reminder to birtles

	David Baron :dbaron: Assignee
	Comment 6 • 9 years ago

And, actually, a try run to check that it's still an issue:
https://treeherder.mozilla.org/#/jobs?repo=try&revision=b1cd12ae251a

	David Baron :dbaron: Assignee
	Comment 7 • 9 years ago

It looks like maybe I can just back out the disabling... tomorrow, though.

	Pulsebot
	Comment 8 • 9 years ago

https://hg.mozilla.org/integration/mozilla-inbound/rev/10b09c193214

	Ryan VanderMeulen [:RyanVM]
	Comment 9 • 9 years ago

https://hg.mozilla.org/mozilla-central/rev/10b09c193214

	Brian Birtles (:birtles)
	Comment 10 • 9 years ago

This appears to still be failing. The failures are being logged in bug 1148949 and appear to pick up right after this landed on m-i. I'll see if I can reproduce on Linux.

	Brian Birtles (:birtles)
	Comment 11 • 9 years ago

I'm able to reproduce this so I'll try to fix it over in bug 1148949.

	David Baron :dbaron: Assignee
	Comment 12 • 9 years ago

Thanks for fixing that so quickly.

(Sorry, probably should have backed this out once it turned out that it wasn't actually fixed, but I guess it's all better now.)