Summary: | [GTK] new test svg/stroke/non-scaling-stroke-pattern.svg fails | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | János Badics <jbadics> | ||||||||
Component: | Tools / Tests | Assignee: | Philip Rogers <pdr> | ||||||||
Status: | RESOLVED FIXED | ||||||||||
Severity: | Normal | CC: | bugs-noreply, cdumez, dpino, gyuyoung.kim, jussi.kukkonen, krit, mcatanzaro, mrobinson, ossy, pdr, pnormand, rakuco, webkit-bug-importer, webkit.review.bot | ||||||||
Priority: | P2 | Keywords: | InRadar | ||||||||
Version: | 528+ (Nightly build) | ||||||||||
Hardware: | Unspecified | ||||||||||
OS: | Unspecified | ||||||||||
Bug Depends on: | |||||||||||
Bug Blocks: | 87008, 104528 | ||||||||||
Attachments: |
|
Description
János Badics
2012-06-04 07:14:27 PDT
I'm sorry for copying wrong links. Let me correct: This new test: svg/stroke/non-scaling-stroke-pattern.svg fails after introduced in r119391 on Qt, GTK and EFL platforms. See http://build.webkit.sed.hu/results/x86-32%20Linux%20Qt%20Release%20-%20Qt5-WebKit1/r119392%20(8214)/svg/stroke/non-scaling-stroke https://bugs.webkit.org/show_bug.cgi?id=88198 I'll have a patch up in a few minutes to fix this. (In reply to comment #2) > I'll have a patch up in a few minutes to fix this. Thank you for the quick reply and for looking into it. Created attachment 145588 [details]
Update test expectations after 119392
Comment on attachment 145588 [details]
Update test expectations after 119392
Wrong patch.
Created attachment 145590 [details]
Update test expectations after 119392
Comment on attachment 145590 [details] Update test expectations after 119392 Clearing flags on attachment: 145590 Committed r119402: <http://trac.webkit.org/changeset/119402> All reviewed patches have been landed. Closing bug. I guess you want to keep this bug open, right? (In reply to comment #9) > I guess you want to keep this bug open, right? Absolutely, thanks Philippe! Created attachment 152860 [details]
Update TestExpectations
Comment on attachment 152860 [details] Update TestExpectations Clearing flags on attachment: 152860 Committed r122903: <http://trac.webkit.org/changeset/122903> All reviewed patches have been landed. Closing bug. It is still valid, but CQ closed it when landing expectations update. (In reply to comment #14) > It is still valid, but CQ closed it when landing expectations update. Is it still valid? I thought one of the refactorings I've been doing in RenderSVGShape fixed it, as the test is now passing on Saf/mac, Cr/linux, Cr/win, and the QT/EFL/GTK bots look to be happy. (In reply to comment #15) > (In reply to comment #14) > > It is still valid, but CQ closed it when landing expectations update. > > Is it still valid? I thought one of the refactorings I've been doing in RenderSVGShape fixed it, as the test is now passing on Saf/mac, Cr/linux, Cr/win, and the QT/EFL/GTK bots look to be happy. For some reason, the test started being flaky on the EFL bots since r129371 on the WK2 bot: <http://build.webkit.org/builders/EFL%20Linux%2064-bit%20Debug%20WK2/builds/3534/steps/layout-test/logs/stdio> and r129372 on the WK1 bot: <http://build.webkit.org/builders/EFL%20Linux%2064-bit%20Debug/builds/6296/steps/layout-test/logs/stdio> (In reply to comment #16) > (In reply to comment #15) > > (In reply to comment #14) > > > It is still valid, but CQ closed it when landing expectations update. > > > > Is it still valid? I thought one of the refactorings I've been doing in RenderSVGShape fixed it, as the test is now passing on Saf/mac, Cr/linux, Cr/win, and the QT/EFL/GTK bots look to be happy. > > For some reason, the test started being flaky on the EFL bots since r129371 on the WK2 bot: <http://build.webkit.org/builders/EFL%20Linux%2064-bit%20Debug%20WK2/builds/3534/steps/layout-test/logs/stdio> and r129372 on the WK1 bot: <http://build.webkit.org/builders/EFL%20Linux%2064-bit%20Debug/builds/6296/steps/layout-test/logs/stdio> And then the flakiness mysteriously stopped in r129380 for the WK1 bot and 129377 for WK2... (In reply to comment #17) > (In reply to comment #16) > > (In reply to comment #15) > > > (In reply to comment #14) > > > > It is still valid, but CQ closed it when landing expectations update. > > > > > > Is it still valid? I thought one of the refactorings I've been doing in RenderSVGShape fixed it, as the test is now passing on Saf/mac, Cr/linux, Cr/win, and the QT/EFL/GTK bots look to be happy. > > > > For some reason, the test started being flaky on the EFL bots since r129371 on the WK2 bot: <http://build.webkit.org/builders/EFL%20Linux%2064-bit%20Debug%20WK2/builds/3534/steps/layout-test/logs/stdio> and r129372 on the WK1 bot: <http://build.webkit.org/builders/EFL%20Linux%2064-bit%20Debug/builds/6296/steps/layout-test/logs/stdio> > > And then the flakiness mysteriously stopped in r129380 for the WK1 bot and 129377 for WK2... This may have been some other test leaving bad state around. I watch this code pretty closely and I don't think there have been any changes here. Mind if we close this again? (In reply to comment #18) > This may have been some other test leaving bad state around. I watch this code pretty closely and I don't think there have been any changes here. > > Mind if we close this again? The test is _very_ flaky on all EFL and GTK bots. I think that's perfectly valid reason to keep a bug open and as this bug wasn't used to fix any particular issue so far it could as well be this one, right? I can reproduce this with --iterations=3 (or larger). For some reason the third one and all subsequent iterations will always fail here. The failure is interesting: there are visual artifacts around the square (I assume this is the pattern area). These artifacts change depending on the number of iterations I tell test runner to do, but they are totally reproducible: e.g. the result for iteration 4 will always be the same. (In reply to comment #20) > The failure is interesting: there are visual artifacts around the square (I assume this is the pattern area). These artifacts change depending on the number of iterations I tell test runner to do, but they are totally reproducible: e.g. the result for iteration 4 will always be the same. This works in minibrowser as well: refresh the window a few times and the problems start appearing. The test(s) filed under this bug have been consistently passing for the last 4000 revisions. Marking bug as fixed. Committed r263254: <https://trac.webkit.org/changeset/263254> |