* SUMMARY Ninety-two SVG layout tests are failing on the Leopard Debug buildbot due to differences in fill color as reported by the dumped render tree. * STEPS TO REPRODUCE Unknown at this time. The tests only seem to be failing on the one buildbot. * RESULTS The fill color differs on the dumped render tree for each of the tests: - RenderPath {rect} [...] [fill={[type=SOLID] [color=#FF0000] [...] + RenderPath {rect} [...] [fill={[type=SOLID] [color=#008000] [...] * REGRESSION This is a recent regression.
- RenderPath {rect} [...] [fill={[type=SOLID] [color=#FF0000] [...] + RenderPath {rect} [...] [fill={[type=SOLID] [color=#008000] [...] Moving from Red to Green seems like a good thing? ;)
http://build.webkit.org/results/Leopard%20Intel%20Debug%20(Tests)/r44472%20(1769)/ Hum... at least this one looks wrong: http://trac.webkit.org/export/44472/trunk/LayoutTests/svg/custom/use-modify-target-symbol.svg http://build.webkit.org/results/Leopard%20Intel%20Debug%20(Tests)/r44472%20(1769)/svg/custom/use-modify-target-symbol-pretty-diff.html
I don't see how a test which is explicitly listing fill="red" could be end up filling 0x008000, unless somehow the CSS color names are off on leopard? We'll need to figure out when this regression started.
I've been poking around on the buildbot a little and haven't been able to work out what's going on. When the tests are run by themselves they pass without any problems. If I run with --nthly=10 then all of the tests pass without problems too. With --nthly=100 two tests fail. It seems a lot like one or more tests are doing something that causes later tests to fail. It's possible that some SVG code is reading uninitialized memory, which happens to be the expected value most of the time but on this machine happens to trigger bogus behavior. I'll keep digging and see if I can come up with anything useful.
I've been focusing on svg/custom/group-opacity.svg, which is typically one of the first tests to fail. Valgrind shows CoreGraphics reading from some uninitialized stack memory while doing color-matching on the PNGs that the test loads. Other than the usual JSCore GC things, there's no other valgrind output. I don't think CG reading from uninitialized memory could cause this failure. I'm running out of ideas on how to track this down though.
The first time that this showed up on the buildbot was with r44388. The last successful run prior to that was r44383. Nothing in that revision range looks relevant. The closest change that looks like it could be relevant is r44379.
<http://trac.webkit.org/changeset/44379> for easy access.
(In reply to comment #6) > The first time that this showed up on the buildbot was with r44388. The last > successful run prior to that was r44383. Nothing in that revision range looks > relevant. The closest change that looks like it could be relevant is r44379. Oddly enough, this seems to be related to Bug 26218 Comment #2, which shows the same revision range causing issues.
(In reply to comment #8) > (In reply to comment #6) > Oddly enough, this seems to be related to Bug 26218 Comment #2, which shows the > same revision range causing issues. The fix for Bug 26218 also fixed this issue: http://trac.webkit.org/changeset/44549