<html>
<head>
<base href="https://bugs.webkit.org/" />
</head>
<body>
<p>
<div>
<b><a class="bz_bug_link
bz_status_NEW "
title="NEW - [GTK][Threaded Compositor] Several flaky tests"
href="https://bugs.webkit.org/show_bug.cgi?id=161242#c20">Comment # 20</a>
on <a class="bz_bug_link
bz_status_NEW "
title="NEW - [GTK][Threaded Compositor] Several flaky tests"
href="https://bugs.webkit.org/show_bug.cgi?id=161242">bug 161242</a>
from <span class="vcard"><a class="email" href="mailto:cgarcia@igalia.com" title="Carlos Garcia Campos <cgarcia@igalia.com>"> <span class="fn">Carlos Garcia Campos</span></a>
</span></b>
<pre>(In reply to <a href="show_bug.cgi?id=161242#c19">comment #19</a>)
<span class="quote">> (In reply to <a href="show_bug.cgi?id=161242#c18">comment #18</a>)
> > (In reply to <a href="show_bug.cgi?id=161242#c17">comment #17</a>)
> > > (In reply to <a href="show_bug.cgi?id=161242#c16">comment #16</a>)
> > > > You are assuming again that there's a single issue.
> > >
> > > No, clearly there were many different issues, as you've fixed three
> > > different issues so far....
> > >
> > > > I think the situation now
> > > > is mostly the same to what we had before switching to the threaded
> > > > compositor.
> > >
> > > Yes, except for the fact that sometimes a bunch of tests pass when they
> > > usually fail. In build #18023 we have 84 unexpected passes; that never
> > > happened before. What's interesting is these tests either always pass or
> > > always fail in a particular run of run-webkit-tests; they are clearly flaky,
> > > but they don't contribute to the flakiness count.
> >
> > We should probably mark them as pass, to see what's wrong when they fail
>
> That don't makes much sense to me.
>
> You can see the failure diff even if they are expected failures. You just
> have to navigate under
> <a href="https://build.webkit.org/results/GTK%20Linux%2064">https://build.webkit.org/results/GTK%20Linux%2064</a>-
> bit%20Release%20%28Tests%29/ to find them.
>
> For example:
>
> 1) Check the unexpected passes at end of build #18023
> <a href="https://build.webkit.org/builders/GTK%20Linux%2064">https://build.webkit.org/builders/GTK%20Linux%2064</a>-
> bit%20Release%20%28Tests%29/builds/18023/steps/layout-test/logs/stdio and
> pick 1
>
> 2) I pick: imported/mozilla/svg/blend-difference-stacking.html
>
> 3) Check that on the next build that test failed. Log of the next build:
> <a href="https://build.webkit.org/builders/GTK%20Linux%2064">https://build.webkit.org/builders/GTK%20Linux%2064</a>-
> bit%20Release%20%28Tests%29/builds/18024/steps/layout-test/logs/stdio <---
> yes it failed
>
> 4) Go to
> <a href="https://build.webkit.org/results/GTK%20Linux%2064">https://build.webkit.org/results/GTK%20Linux%2064</a>-
> bit%20Release%20%28Tests%29/ and find the results for build #18204 ->
> <a href="https://build.webkit.org/results/GTK%20Linux%2064">https://build.webkit.org/results/GTK%20Linux%2064</a>-
> bit%20Release%20%28Tests%29/r205335%20%2818024%29/
>
> 5) Now under that folder navigate to imported/mozilla/svg/ and look for the
> blend-difference-stacking diff
>
> 6) Here you have it:
> <a href="https://build.webkit.org/results/GTK%20Linux%2064">https://build.webkit.org/results/GTK%20Linux%2064</a>-
> bit%20Release%20%28Tests%29/r205335%20%2818024%29/imported/mozilla/svg/blend-
> difference-stacking-diffs.html</span >
hmm, well, not very convenient, but still. I have theory, though. When they unexpectedly pass, they don't actually pass, we just fail to render both the actual and expected files in the same way (for example a fully white image in both cases). That's a problem of the reftests. So, more interesting to see what's failing, which can be also reproduced locally more easily, would be to see what we render when they pass.</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are the assignee for the bug.</li>
</ul>
</body>
</html>