Red Hat Bugzilla – Bug 1467368
totem doesn't work in VMs under Wayland
Last modified: 2017-09-24 07:04:57 EDT
Description of problem:
It seems not possible to play a video in totem in a VM. Totem window either not appears at all (if you launch it from nautilus), but audio plays in background (with no way to quit it), or totem UI gets frozen (if you open totem beforehand). During that time, I see these errors in terminal:
(totem-video-thumbnailer:2455): dconf-CRITICAL **: unable to create file '/run/user/1000/dconf/user': Permission denied. dconf will not work properly.
I don't see anything in system journal during that time.
The file exists and has correct permissions:
$ ls -l /run/user/1000/dconf/user
-rw-------. 1 kparal kparal 2 Jul 3 16:32 /run/user/1000/dconf/user
You need to kill totem to stop it. Once you do that, you can't launch totem anymore, even after reboot. The only printout in terminal is:
(totem:2278): Gdk-WARNING **: Native Windows taller than 65535 pixels are not supported
If I remove ~/.config/totem/session_state.xspf, it's possible to start totem again (until you play video again).
The file contents is:
$ cat .config/totem/session_state.xspf
<?xml version="1.0" encoding="UTF-8"?>
<playlist version="1" xmlns="http://xspf.org/ns/0/">
I tested everything with this video:
but I also tried an audio file which causes exactly the same issues:
Version-Release number of selected component (if applicable):
see attachment 1293789 [details] for a list of installed packages
Steps to Reproduce:
1. download the video linked above
2. try to play it in totem
totem either freezes or doesn't appear at all, can no longer be started (even after reboot)
This might also apply to basic video driver bare metal systems, but I haven't tested that. Accelerated bare metal systems work fine.
This seems to violate:
"All applications that can be launched using the standard graphical mechanism of a release-blocking desktop after a default installation of that desktop must start successfully and withstand a basic functionality test. "
In a VM, I'm getting that same error message, but note that _audio_ plays when I run `totem trailer_400p.ogg`
Same situation with http://techslides.com/demos/sample-videos/small.webm
Works in X11. Given the late date, can we CommonBugs this and see if we can get a zero-day update?
I notice that in X11 there is the warning:
(totem:3513): Gtk-WARNING **: Drawing a gadget with negative dimensions. Did you forget to allocate a size? (node slider owner GtkScale)
instead of this under Wayland:
(totem:4421): Gdk-WARNING **: Native Windows taller than 65535 pixels are not supported
I wonder if this is the same problem with different consequences under X11 and Wayland?
(On the other hand, those warnings/errors show up on hardware where this works in Wayland too, so might just be red herring.)
FWIW GDK_BACKEND=x11 under Wayland also works.
Discussed at 2017-07-03 blocker review meeting: https://meetbot-raw.fedoraproject.org/fedora-blocker-review/2017-07-03/f26-blocker-review.2017-07-03-16.06.html . We're somewhat concerned about this bug, but we do not yet have sufficiently precise details on the affected configurations and possible workarounds. We will be investigating further to try and pin down just which configurations are and are not affected by this, and will make a blocker decision once we have better information.
This is the stack trace of the hang I requested yesterday:
#0 0x00007fe7701c1aad in poll () from /lib64/libc.so.6
#1 0x00007fe774f9a7d9 in wl_display_poll () from /lib64/libwayland-client.so.0
#2 0x00007fe774f9be1c in wl_display_dispatch_queue () from /lib64/libwayland-client.so.0
#3 0x00007fe75d4ea643 in dri2_wl_swrast_put_image2 () from /lib64/libEGL_mesa.so.0
#4 0x00007fe75d4ea82d in dri2_wl_swrast_put_image () from /lib64/libEGL_mesa.so.0
#5 0x00007fe74f505bd6 in drisw_put_image () from /usr/lib64/dri/swrast_dri.so
#6 0x00007fe74f50610a in drisw_swap_buffers () from /usr/lib64/dri/swrast_dri.so
#7 0x00007fe75d4e8666 in dri2_wl_swrast_swap_buffers () from /lib64/libEGL_mesa.so.0
#8 0x00007fe75d4dc59e in eglSwapBuffers () from /lib64/libEGL_mesa.so.0
#9 0x00007fe77609051d in _cogl_winsys_onscreen_swap_buffers_with_damage () from /lib64/libcogl.so.20
#10 0x00007fe77607a406 in cogl_onscreen_swap_buffers_with_damage () from /lib64/libcogl.so.20
#11 0x00007fe77672900d in clutter_stage_cogl_redraw () from /lib64/libclutter-1.0.so.0
#12 0x00007fe77672bff5 in clutter_stage_gdk_redraw () from /lib64/libclutter-1.0.so.0
#13 0x00007fe776796782 in _clutter_stage_do_update () from /lib64/libclutter-1.0.so.0
#14 0x00007fe77672bc85 in clutter_master_clock_gdk_update () from /lib64/libclutter-1.0.so.0
#15 0x00007fe7709cf30d in g_closure_invoke () from /lib64/libgobject-2.0.so.0
#16 0x00007fe7709e198e in signal_emit_unlocked_R () from /lib64/libgobject-2.0.so.0
#17 0x00007fe7709ea1a5 in g_signal_emit_valist () from /lib64/libgobject-2.0.so.0
#18 0x00007fe7709eab0f in g_signal_emit () from /lib64/libgobject-2.0.so.0
#19 0x00007fe771dc09c1 in gdk_frame_clock_paint_idle () from /lib64/libgdk-3.so.0
#20 0x00007fe771dabb20 in gdk_threads_dispatch () from /lib64/libgdk-3.so.0
#21 0x00007fe7706f7cad in g_timeout_dispatch () from /lib64/libglib-2.0.so.0
#22 0x00007fe7706f7247 in g_main_context_dispatch () from /lib64/libglib-2.0.so.0
#23 0x00007fe7706f75e8 in g_main_context_iterate.isra () from /lib64/libglib-2.0.so.0
#24 0x00007fe7706f767c in g_main_context_iteration () from /lib64/libglib-2.0.so.0
#25 0x00007fe770cb0ebd in g_application_run () from /lib64/libgio-2.0.so.0
#26 0x000055cdd62a2078 in main ()
Reassigning this to clutter, although it might be a clutter-gst or clutter-gtk issue. Cheese hangs in the exact same way.
For consistency with #1467599, I'm -1 to this as a blocker when weighing the impact vs. time. There was a little more time for this one, but the impact is less.
cirrus fails to boot. vmvga boots to X11 (so 'works'). SPICE or VNC makes no difference to the outcome with any driver.
VirtualBox (5.1.22, on Windows) boots to X11, so 'works'.
Both my attempts to boot the live image on VMware Player on Windows failed, which seems a little concerning. Be good if anyone else can confirm/deny.
Discussed at 2017-07-06 Fedora 26 Final Go/No-Go meeting, acting as a blocker review meeting: https://meetbot-raw.fedoraproject.org/fedora-meeting-2/2017-07-06/f26_final_gono-go_meeting.2017-07-06-17.00.html . This is a conditional violation (only in the case of certain VM configurations) which means it's a subjective decision, taking into consideration the severity of the bug, how common the affected configurations are, and how well the bug can be worked around. We decided to reject it as a blocker after considering these factors; the known affected cases and workarounds will be documented in the Common Bugs page.
> This affects:
> cirrus fails to boot. vmvga boots to X11 (so 'works'). SPICE or VNC makes no
> difference to the outcome with any driver.
> VirtualBox (5.1.22, on Windows) boots to X11, so 'works'.
I suspect this might be a mesa swrast/llvmpipe driver bug which I believe would be the default driver with all the above options. From experience for device specific issues it's rarely a clutter bug but lower down the stack at driver level else we tend to see it as a generic crash everywhere
Meta: I'm reporting similar problems _on Debian_. I'm aware this bug is about Fedora, but I've not found any upstream bug report about it and I see GNOME developers involved in the discussion here, so I'm sharing my info in the hope it helps classifying and reporting this bug to the correct upstream project. If that's not welcome just let me know :)
I'm experiencing this bug, with the sample videos linked above, on current Debian unstable i.e. the closest we have to Rawhide (mostly GNOME 3.26 with some bits still at 3.24 or even 3.22), in two different environments:
1. libvirt/QEMU VM with QXL graphics
2. Acer Chromebook R 13 CB5-312T: arm64, PowerVR GX6250 GPU that's supported by drm/mediatek in the kernel, but has no DRI module for Mesa
In both cases:
* Totem 3.26.0, GStreamer 1.12.3, Clutter 1.26.2, GNOME Shell 3.22.3 (but I could reproduce with 3.26 too), Wayland 1.14.0
* The sound track is played correctly.
* I'm running GNOME Shell under Wayland.
* I can't reproduce the bug with GDK_BACKEND=x11.
* I can't reproduce the bug in GNOME Shell under Xorg.
* llvmpipe is used
* Mesa 17.2.1 built with llvm 5.0
This tends to confirm the "mesa swrast/llvmpipe driver bug" hypothesis, and it implies that not only VMs are affected, but quite possibly any system that has no DRI module for Mesa is too.
I can't reproduce on current Debian stable (Stretch) with mesa 13.0.6 in libvirt/QEMU.
Let me know if there's any other info I should share, e.g. I'm happy to get whatever backtrace might help.
(In reply to intrigeri from comment #14)
> * Mesa 17.2.1 built with llvm 5.0
Err, no: Mesa was built using llvm 3.8, but the installed libllvm is 5.0 (and apparently that's what About reports about).
On today's Ubuntu artful live system (they build Mesa with llvm 5.0 and ship the same version) I can't reproduce this bug.