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)
r52553 definitely ran clean: http://build.webkit.org/builders/Leopard%20Intel%20Debug%20%28Tests%29/builds/8650
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.
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.
I've kicked off a rollout. Should land shortly.
Committed r52569: <http://trac.webkit.org/changeset/52569>
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.
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.
It's possible the failures before were a bogus ASSERT. I never tried to reproduce them locally.
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*))
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.
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.
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.
(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.
(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?