WebKit Bugzilla
New
Browse
Search+
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED FIXED
32955
REGRESSION(52554): Two layout test failures on Leopard Debug after
r52554
(partial? rollout of
r52536
)
https://bugs.webkit.org/show_bug.cgi?id=32955
Summary
REGRESSION(52554): Two layout test failures on Leopard Debug after r52554 (pa...
Eric Seidel (no email)
Reported
2009-12-26 20:40:41 PST
REGRESSION(52554): Two layout test failures on Leopard after
r52554
(partial? rollout of
r52536
)
http://build.webkit.org/results/Leopard%20Intel%20Debug%20(Tests)/r52555%20(8652)/results.html
http://trac.webkit.org/changeset/52554
The previous build was clean. The bots have been red since that checkin. I suggest we rollout this rollout even if that means breaking Chromium. Or we Skip the offending tests. Breaking Leopard is not cool. :( I have no clue what the problem with the SVG test is. Tests where results did not match expected results: svg/W3C-SVG-1.1/filters-conv-01-f.svg expected actual diff pretty diff Tests that caused the DumpRenderTree tool to crash: storage/open-database-while-transaction-in-progress.html stderr --- layout-test-results/svg/W3C-SVG-1.1/filters-conv-01-f-expected.txt 2009-12-24 22:24:25.000000000 -0800 +++ layout-test-results/svg/W3C-SVG-1.1/filters-conv-01-f-actual.txt 2009-12-24 22:24:25.000000000 -0800 @@ -39,7 +39,7 @@ RenderSVGImage {image} at (180,163) size 50x63 [filter=convolve5] RenderSVGText {text} at (10,20) size 117x18 contains 1 chunk(s) RenderSVGInlineText {#text} at (0,-14) size 117x18 - chunk 1 text run 1 at (10.00,20.00) startOffset 0 endOffset 19 width 117.00: "Vertical blur (1x3)" + chunk 1 text run 1 at (10.00,20.00) startOffset 0 endOffset 19 width 115.00: "Vertical blur (1x3)" RenderSVGContainer {g} at (330,163) size 50x63 [transform={m=((1.00,0.00)(0.00,1.00)) t=(300.00,93.00)}] RenderSVGImage {image} at (330,163) size 50x63 [filter=convolve6] RenderSVGText {text} at (10,340) size 264x46 contains 1 chunk(s)
Attachments
Add attachment
proposed patch, testcase, etc.
Eric Seidel (no email)
Comment 1
2009-12-26 20:49:13 PST
r52553
definitely ran clean:
http://build.webkit.org/builders/Leopard%20Intel%20Debug%20%28Tests%29/builds/8650
Eric Seidel (no email)
Comment 2
2009-12-26 21:01:49 PST
I meant to link to build
http://build.webkit.org/builders/Leopard%20Intel%20Debug%20%28Tests%29/builds/8651
instead of 8652 in my initial message. 8652 corresponds to
r52554
and is the first build we saw failures from.
Eric Seidel (no email)
Comment 3
2009-12-26 21:08:31 PST
I'm updating my tree and then I will make a rollout of (
r52554
). I've notified the #chromium channel, as according to build.chromium.org no one is sheriff today.
Eric Seidel (no email)
Comment 4
2009-12-26 23:27:45 PST
I've kicked off a rollout. Should land shortly.
Eric Seidel (no email)
Comment 5
2009-12-26 23:36:41 PST
Committed
r52569
: <
http://trac.webkit.org/changeset/52569
>
Eric Seidel (no email)
Comment 6
2009-12-26 23:53:47 PST
Looks like this breaks 21 tests for Chromium:
http://build.chromium.org/buildbot/layout_test_results/webkit-rel-linux-webkit-org/35287/index-14120.html
However, if it passes on Leopard (and thus makes the WebKit builders green again), I plan to leave the change in for now.
Eric Seidel (no email)
Comment 7
2009-12-26 23:56:12 PST
The 21 test failures for Chromium are: Threw exception Error: INVALID_STATE_ERR: DOM Exception 11 when doing database operations. Dumi's commentary would be helpful here.
Eric Seidel (no email)
Comment 8
2009-12-26 23:58:48 PST
It's possible the failures before were a bogus ASSERT. I never tried to reproduce them locally.
Eric Seidel (no email)
Comment 9
2009-12-26 23:59:16 PST
Yes, looks like the Leopard ASSERT was: ASSERTION FAILED: m_openDatabaseSet && m_openDatabaseSet->contains(database) (/Volumes/Big/WebKit-BuildSlave/leopard-intel-debug/build/WebCore/dom/Document.cpp:4448 void WebCore::Document::removeOpenDatabase(WebCore::Database*))
Nikolas Zimmermann
Comment 10
2009-12-27 05:38:32 PST
The svg test only fails if another test crashes before. I have _no_ clue what causes text metrics differences, if a test crashed before that filters-conv-01-f test. Indicates a DRT problem.
Shinichiro Hamaji
Comment 11
2009-12-27 06:59:03 PST
Oops... I'm so sorry about this re-regression, and thanks Eric for landing the fix. I should have checked webkit build bot (I usually check the bots after I land a patch, but in this case I couldn't imagine reverting a change can cause regression)... Adding Pam in CC list of this bug as he is the next webkit gardener of chromium. I guess we may want to disable the 21 tests in chromium side if Dumi is on year end vacation.
Eric Seidel (no email)
Comment 12
2009-12-27 08:28:39 PST
Niko: I expect that DRT crashing just causes DRT to restart at the right point to trigger interaction between the SVG tests. I expect that we could cause the SVG test to fail in other circumstances (including jus running every test after storage/open-database-while-transaction-in-progress.html). I've not yet attempted to reproduce it locally. Counting tests, it looks like there are about 1000 tests between storage/open-database-while-transaction-in-progress.html and svg/W3C-SVG-1.1/filters-conv-01-f.svg. Sinchiro: Thank you. I expect that the 21 tests all have a single root cause. I also expect that the ASSERT seen on Leopard also has a simple resolution. I do not feel comfortable enough with this code to guess off the top of my head, but I expect that someone like Dumi might know.
Nikolas Zimmermann
Comment 13
2009-12-27 09:16:56 PST
(In reply to
comment #12
)
> Niko: I expect that DRT crashing just causes DRT to restart at the right point > to trigger interaction between the SVG tests. I expect that we could cause the > SVG test to fail in other circumstances (including jus running every test after > storage/open-database-while-transaction-in-progress.html). I've not yet > attempted to reproduce it locally.
The problem are not the SVG tests, I've already investigated. If I run just "run-webkit-tests svg" I can reproduce the filters-conv-01-f.svg bug on my machine, everytime! If DRT crashes ~ 1000 tests before the SVG test, and restarts, the problem with filters-conv-01-f.svg appears. So some test is modifying text metrics for all following tests, no idea why.
Dirk Schulze
Comment 14
2009-12-27 09:51:52 PST
(In reply to
comment #13
)
> The problem are not the SVG tests, I've already investigated. If I run just > "run-webkit-tests svg" I can reproduce the filters-conv-01-f.svg bug on my > machine, everytime! If DRT crashes ~ 1000 tests before the SVG test, and > restarts, the problem with filters-conv-01-f.svg appears. So some test is > modifying text metrics for all following tests, no idea why.
But it's strange if it allways fails on filters-conv-01-f.svg?
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug