Bug 132126 - [GTK] At least 13 animations/* tests and 5 media/* tests fail, crash or timeout if XVFB_SCREEN_DEPTH=8 is not set
Summary: [GTK] At least 13 animations/* tests and 5 media/* tests fail, crash or timeo...
Status: REOPENED
Alias: None
Product: WebKit
Classification: Unclassified
Component: Tools / Tests (show other bugs)
Version: 528+ (Nightly build)
Hardware: Other Linux
: P2 Normal
Assignee: Nobody
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-04-24 08:18 PDT by Carlos Alberto Lopez Perez
Modified: 2020-02-19 14:24 PST (History)
17 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Carlos Alberto Lopez Perez 2014-04-24 08:18:39 PDT
The GTK release bot has been running with the environment variable XVFB_SCREEN_DEPTH=8 for a while. That variable was added on https://bugs.webkit.org/show_bug.cgi?id=121951 to workaround a bug related with Xvfb not able to provide GL software rendering with 24 bits depth.

After some upgrades, this is not longer a problem and GL rendering seems to work as expected on Xvfb on the GTK release bot.

The test that I did was to launch the jhbuilded Xvfb manually and check the output of glxinfo.

clopez@bb-webkit-rel-64: ~ $ /home/slave/webkitgtk/gtk-linux-64-release/build/WebKitBuild/Dependencies/Root/bin/Xvfb :127 -screen 0 800x600x24 -nolisten tcp

clopez@bb-webkit-rel-64: ~ $ DISPLAY=:127 glxinfo|grep render
direct rendering: Yes
    GLX_MESA_multithread_makecurrent, GLX_MESA_query_renderer, 
OpenGL renderer string: Gallium 0.4 on llvmpipe (LLVM 3.4, 128 bits)
    GL_MESA_ycbcr_texture, GL_NV_blend_square, GL_NV_conditional_render, 


So we decided to remove this workaround in order to have the release bot running with an environment more similar to the one that is used by the developers.

However, after we removed this workaround we detected that at least 13 animations/* test started to fail. The tests are the following:

animations/3d/transform-origin-vs-functions.html
animations/combo-transform-translate+scale.html
animations/play-state.html
animations/3d/change-transform-in-end-event.html
animations/added-while-suspended.html
animations/animation-iteration-event-destroy-renderer.html
animations/animation-direction-normal.html
animations/animation-direction-reverse.html
animations/play-state-paused.html
animations/play-state-suspend.html
animations/suspend-resume-animation.html
animations/transform-non-accelerated.html
animations/body-removal-crash.html

The last build with XVFB_SCREEN_DEPTH=8 was http://build.webkit.org/builders/GTK%20Linux%2064-bit%20Release/builds/46788 and the first one without that variable was http://build.webkit.org/builders/GTK%20Linux%2064-bit%20Release/builds/46789

This behaviour is reproducible on my laptop. If I do "export XVFB_SCREEN_DEPTH=8" before running the tests, all this tests pass as expected. If I do "unset XVFB_SCREEN_DEPTH" before running them, the test fail or timeout.
Comment 1 Carlos Alberto Lopez Perez 2014-04-24 09:01:37 PDT
The following tests also fail in a reproducible way if XVFB_SCREEN_DEPTH=8 is not set:

  fast/dom/Window/window-resize-and-move-arguments.html [ Timeout ]
  fast/text/international/embed-bidi-style-in-isolate-crash.html [ Timeout ]
  media/restore-from-page-cache.html [ Crash ]
  media/video-poster-background.html [ ImageOnlyFailure ]
  platform/gtk/editing/pasteboard/middle-button-paste.html [ Failure Pass ]



On top of that, the following tests failed also on the bot (after removing XVFB_SCREEN_DEPTH=8), but I'm not able to reproduce the behaviour on my laptop by setting/unsetting this variable. So probably this later ones are related to another issue. Just pasting here for reference:

  media/media-fragments/TC0087.html [ Failure Pass ]
  fast/sub-pixel/simple-clipping.html [ ImageOnlyFailure Pass ]
  fast/dom/Window/window-resize-and-move-sub-frame.html [ Timeout Pass ]
  fast/events/touch/touch-input-element-change-documents.html [ Failure Timeout ]
  fast/workers/worker-close.html [ Timeout Pass ]
  fast/writing-mode/Kusa-Makura-background-canvas.html [ Failure Timeout ]
  http/tests/media/video-redirect.html [ Timeout Pass ]
  http/tests/misc/iframe-reparenting-id-collision.html [ Crash Timeout Pass ]
  inspector-protocol/page/deny-X-FrameOption.html [ Failure Timeout Pass ]
  jquery/event.html [ Timeout Pass ]
  js/dfg-int16array.html [ Timeout Pass ]
  js/dfg-int32-to-double-on-known-number.html [ Timeout Pass ]
  js/dfg-int32array-overflow-values.html [ Timeout Pass ]
  js/dfg-int32array.html [ Timeout Pass ]
  js/dfg-int8array.html [ Timeout Pass ]
  js/dom/random-array-gc-stress.html [ Crash Timeout Pass ]
  media/track/track-cues-cuechange.html [ Timeout Pass ]
  media/track/track-cues-enter-exit.html [ Timeout Pass ]
  media/volume-bar-empty-when-muted.html [ Failure ]
Comment 2 Carlos Alberto Lopez Perez 2014-04-24 10:50:22 PDT
I committed r167765 <https://trac.webkit.org/r167765> to update the test expectations with the tests that I was able to successful correlate with this issue and also I was able to reproduce the behaviour . 

This is what happens when the environment variable XVFB_SCREEN_DEPTH=8 is not set:

animations/3d/transform-origin-vs-functions.html [ Failure Pass ] 
animations/combo-transform-translate+scale.html [ Failure Pass ] 
animations/play-state.html [ Failure Pass ] 
animations/3d/change-transform-in-end-event.html [ Timeout Pass ] 
animations/added-while-suspended.html [ Timeout Pass ] 
animations/animation-iteration-event-destroy-renderer.html [ Timeout Pass ] 
animations/animation-direction-normal.html [ Failure Pass ] 
animations/animation-direction-reverse.html [ Failure Pass ] 
animations/play-state-paused.html [ Failure ] 
animations/play-state-suspend.html [ Failure ] 
animations/suspend-resume-animation.html [ Failure ] 
animations/transform-non-accelerated.html [ Failure ] 
animations/body-removal-crash.html [ Crash Pass ] 
media/track/track-cues-cuechange.html [ Timeout Pass ] 
media/track/track-cues-cuechange.html [ Timeout Pass ] 
media/track/track-cues-enter-exit.html [ Timeout Pass ] 
media/video-poster-background.html [ ImageOnlyFailure ] 
media/restore-from-page-cache.html [ Crash ] 


If the environment variable XVFB_SCREEN_DEPTH=8 is set all this tests pass without problems.
Comment 3 Martin Robinson 2014-04-24 11:46:29 PDT
Does this improve with the use of the llvpipe software rasterizer?
Comment 4 Carlos Alberto Lopez Perez 2014-04-24 14:42:18 PDT
(In reply to comment #3)
> Does this improve with the use of the llvpipe software rasterizer?

My understanding is that right now, it is already using it. Check what I commented on comment #0

[....]
> After some upgrades, this is not longer a problem and GL rendering seems to work as expected on Xvfb on the GTK release bot.
> The test that I did was to launch the jhbuilded Xvfb manually and check the output of glxinfo.
> 
> clopez@bb-webkit-rel-64: ~ $ /home/slave/webkitgtk/gtk-linux-64-release/build/WebKitBuild/Dependencies/Root/bin/Xvfb :127 -screen 0 800x600x24 -nolisten tcp
> 
> clopez@bb-webkit-rel-64: ~ $ DISPLAY=:127 glxinfo|grep render
> direct rendering: Yes
>     GLX_MESA_multithread_makecurrent, GLX_MESA_query_renderer, 
> OpenGL renderer string: Gallium 0.4 on llvmpipe (LLVM 3.4, 128 bits)
>     GL_MESA_ycbcr_texture, GL_NV_blend_square, GL_NV_conditional_render, 
> 
[...]


Do you have in mind another command or patch that I can try?
Comment 5 Martin Robinson 2014-04-24 20:16:12 PDT
(In reply to comment #4)
> (In reply to comment #3)
> > Does this improve with the use of the llvpipe software rasterizer?
> 
> My understanding is that right now, it is already using it. Check what I commented on comment #0

Oh. You're right. Do you know what version of Mesa?
Comment 6 Carlos Alberto Lopez Perez 2014-04-25 03:06:46 PDT
(In reply to comment #5)
> Do you know what version of Mesa?

Mesa 10.1.0-5 from Debian testing. Specifically the following packages are installed:


bb-webkit-rel-64 ~ # dpkg-query -W --showformat='${Source} ${Version} ${Package}\n'|grep "^mesa "
mesa 10.1.0-5 libegl1-mesa
mesa 10.1.0-5 libegl1-mesa-dev
mesa 10.1.0-5 libegl1-mesa-drivers
mesa 10.1.0-5 libgbm1
mesa 10.1.0-5 libgl1-mesa-dev
mesa 10.1.0-5 libgl1-mesa-dri
mesa 10.1.0-5 libgl1-mesa-glx
mesa 10.1.0-5 libglapi-mesa
mesa 10.1.0-5 libgles2-mesa
mesa 10.1.0-5 libopenvg1-mesa
mesa 10.1.0-5 libwayland-egl1-mesa
mesa 10.1.0-5 mesa-common-dev
Comment 7 Víctor M. Jáquez L. 2014-08-21 04:10:46 PDT
media/restore-from-page-cache.html was fixed with http://trac.webkit.org/changeset/172828
Comment 8 Michael Catanzaro 2016-01-08 12:53:37 PST
The following animation tests:

  animations/play-state-paused.html [ Failure ]
  animations/play-state-suspend.html [ Failure ]
  animations/suspend-resume-animation.html [ Failure ]
  animations/transform-non-accelerated.html [ Failure ]

started unexpectedly passing in r190615, though they were expected to fail. This is because r190615 accidentally turned off accelerated compositing. In r191101 the tests were unskipped because they were passing. In r191102 (one revision later, accelerated compositing was reenabled, and the tests have been failing again ever since.

So the tests were passing with a failure expectation, then the failure expectation was removed immediately before the tests started failing. :)
Comment 9 Michael Catanzaro 2016-07-23 09:46:49 PDT
All of these tests were fixed by the switch to threaded compositor. Updating expectations accordingly.
Comment 10 Michael Catanzaro 2016-07-23 09:47:50 PDT
Just kidding, only the tests mentioned in comment #8 started passing. The following test are all still failing:

# This failures only seem to happen if the environment variable XVFB_SCREEN_DEPTH=8 is not set
webkit.org/b/132126 animations/3d/transform-origin-vs-functions.html [ Failure Pass ]
webkit.org/b/132126 animations/combo-transform-translate+scale.html [ Failure Pass ]
webkit.org/b/132126 animations/play-state.html [ Failure Pass ]
webkit.org/b/132126 animations/3d/change-transform-in-end-event.html [ Timeout Pass ]
webkit.org/b/132126 animations/added-while-suspended.html [ Timeout Pass ]
webkit.org/b/132126 animations/animation-iteration-event-destroy-renderer.html [ Timeout Pass Crash ]
webkit.org/b/132126 animations/animation-direction-normal.html [ Failure Pass ]
webkit.org/b/132126 animations/animation-direction-reverse.html [ Crash Failure Pass ]
webkit.org/b/132126 animations/body-removal-crash.html [ Crash Pass ]
webkit.org/b/132126 media/track/track-cues-cuechange.html [ Timeout Pass ]
webkit.org/b/132126 media/track/track-cues-enter-exit.html [ Timeout Pass ]
webkit.org/b/132126 media/video-poster-background.html [ ImageOnlyFailure ]
Comment 11 Michael Catanzaro 2016-07-23 09:55:24 PDT
Well just kidding about that too, they all have Pass expectations, and I forgot to check them individually. All the animations tests are passing now, too. Only the media tests remain failing after the switch to threaded compositor:

webkit.org/b/132126 media/track/track-cues-cuechange.html [ Timeout Pass ]
webkit.org/b/132126 media/track/track-cues-enter-exit.html [ Timeout Pass ]
webkit.org/b/132126 media/video-poster-background.html [ ImageOnlyFailure ]
Comment 12 Miguel Gomez 2018-11-15 06:28:36 PST
media/video-poster-background.html
is passing since r238090
Comment 13 Lauro Moura 2020-02-19 14:24:56 PST
media/track/track-cues-enter-exit.html and media/track/track-cues-cuechange.html have not failed nor timed out since r237576 (Oct 2018) and before that r218268 (Jun 2017), being affected by bug198830 instead.