Bug 1467368

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. "
https://fedoraproject.org/wiki/Fedora_26_Final_Release_Criteria#Default_application_functionality

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.

This affects:

virtio
qxl
vga

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:
> 
> virtio
> qxl
> vga
> 
> 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.

This is still the case with F28 Beta Workstation.

This message is a reminder that Fedora 26 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 26. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '26'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not
able to fix it before Fedora 26 is end of life. If you would still like
to see this bug fixed and are able to reproduce it against a later version
of Fedora, you are encouraged  change the 'version' to a later Fedora
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.

This happens also on Fedora 29.

This message is a reminder that Fedora 29 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora 29 on 2019-11-26.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
Fedora 'version' of '29'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 29 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

This is working just fine in Fedora 31 GA image (totem-3.34.1-1.fc31.x86_64). At least with virtio driver.