[Webkit-unassigned] [Bug 161242] [GTK][Threaded Compositor] Several flaky tests

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=161242

--- Comment #3 from Carlos Garcia Campos <cgarcia at igalia.com> ---
(In reply to comment #2)
> (In reply to comment #0)
> > Even after fixing bug #160450 we still have a lot of laky tests sometimes in
> > the bots. We no longer see the problem of scrollbars partially rendered, but
> > we see scrollbars in some cases where they shouldn't be there at all (the
> > contents are not bigger than the view size). That made me think that maybe
> > there are tests leaving the view in an inconsistent state, most of the flaky
> > tests are ref tests and all run by the same worker. But I tried to run all
> > the tests using a single worker and I couldn't reproduce the problem so
> > there must be something else. The other thing I can think of is that maybe
> > in some cases the bot is more overloaded and a particular worker has less
> > priority and things happen slower. We are still assuming that scheduling the
> > task in the next loop iteration in the UI process after a force redraw
> > ensures a redraw. The patch I initially posted in bug #160450 as a
> > workaround tried to fix that assumption. I'm not sure that's the problem
> > though, but we could try that patch and roll it out if it doesn't work. I'm
> > a bit lost with this, because it only happens sometimes in the bots and I've
> > never been able to reproduce it locally in any of machines I've tried.
> 
> I think you will be able to reproduce this if you run the whole test suite
> instead a subset of it.

I did run all the tests using a single worker.

> And this is something that I believe was happening before the threaded
> compositor with other kind of tests.
> 
> I have found many tests that are flaky when the whole test suite is run, but
> if you run then manually or you run a subset of the test suite (for example:
> run only the fast/ tests). Then its not longer reproducible.
> 
> I'm not sure if the problem is on webkit itself or is in the tooling and the
> way the tests are ran.

I'm pretty sure the problem is in the tests infrastructure.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.webkit.org/pipermail/webkit-unassigned/attachments/20160827/df76372c/attachment.html>