GNOME Bugzilla – Bug 777289
Gnome wayland session freezes on mouse hovering over slider in VLC
Last modified: 2021-07-05 13:51:31 UTC
Note: this may or may not be related to or a dup of the bug 774557. When the mouse pointer hovers over the time slider (time toolbar indicator) in the vlc gui, gnome shell sometimes freezes completely on a single-screen system running F25 workstation. "Sometimes" here means that there are peculiarity in reproducing this problem (see below), but it is 100% reproducible in the current environment since the very first day F25 was released until now: ▪ can reproduce this problem while playing audio files in vlc ▪ the first audio track in a newly launched vlc instance usually does not reveal this problem, but the the second and susequent ones do; this means you should not restart vlc, but launch next tracks from within the same vlc process or from nautilus; if you restart vlc, you'll have to wait until the second track in the same vlc process to be able to freeze gnome session ▪ a possible workaround to prevent the freeze is to quickly (within 2-5 secs) move the mouse pointer to the top left screen corner switching to the activities window; this mostly works for the first time, but usually does not for the second ▪ gnome session becomes completely unresponsive to any key sequences (including switching to consoles C+F1...F6) and to any mouse motions/clicks, but the backend apps of course continue to function successfully System: 4.9.3-200.fc25.x86_64 #1 SMP Fri Jan 13 01:01:13 UTC 2017 x86_64 GNU/Linux Screen 0: minimum 320 x 200, current 2560 x 1600, maximum 8192 x 8192 XWAYLAND0 connected 2560x1600+0+0 640mm x 400mm 2560x1600 59.94*+ Related packages: gnome-shell-3.22.2-2.fc25.x86_64 gnome-session-wayland-session-3.22.2-1.fc25.x86_64 mutter-3.22.2-3.fc25.x86_64 xorg-x11-server-Xwayland-1.19.1-1.fc25.x86_64 libwayland-server-1.12.0-1.fc25.i686 libwayland-server-1.12.0-1.fc25.x86_64 libwayland-client-1.12.0-1.fc25.i686 libwayland-client-1.12.0-1.fc25.x86_64 mesa-libwayland-egl-13.0.3-1.fc25.x86_64 libwayland-cursor-1.12.0-1.fc25.x86_64 ibus-wayland-1.5.14-5.fc25.x86_64
What you describe reminds me of https://bugzilla.redhat.com/show_bug.cgi?id=1278159 which is mitigated by https://cgit.freedesktop.org/xorg/xserver/commit/?id=b79eaf11
To be clear, if you are using Fedora 25, you already have commit b79eaf1 in the Xserver 1.19.x, what you experience here is the mitigation, as otherwise your entire session would crash. Details of the discussions that occurred around that issue can be found here: https://lists.x.org/archives/xorg-devel/2016-September/051058.html
I think it makes a little difference to a user what do we call this case - mitigation or crash. Because the only workaround when this occurs would be HW resets, one cannot just switch to any console and then restart corresponding processes without rebooting. I had to switch to Xorg from Wayland for the time being as this happens very frequently when the mouse traverses over the VLC slider. Or otherwise I use cvlc.
*** Bug 784902 has been marked as a duplicate of this bug. ***
This bug is actual a dupe of bug 777428, and vlc has a patch to avoid the issue: https://trac.videolan.org/vlc/ticket/17829
The problem still persists in Fedora 27. The patch referred in the previous comment was recommended to be reverted as it was "bad". I think an app by no means should be able to freeze lower sw layers. Environment: 4.16.16-200.fc27.x86_64 #1 SMP Sun Jun 17 03:06:00 UTC 2018 x86_64 gnome-shell-3.26.2-5.fc27.x86_64 gnome-session-wayland-session-3.26.1-1.fc27.x86_64 mutter-3.26.2-3.fc27.x86_64 xorg-x11-server-Xwayland-1.19.6-7.fc27.x86_64 ibus-wayland-1.5.17-6.fc27.x86_64 vlc-3.0.3-2.fc27.x86_64
I'm not sure if this reallt is a dupe of bug 777428 because I run into this problem exclusively in the audio mode (without playing any video and expanding the VLC window to the full screen).
Still a problem in Fedora 28. Full screen or no full screen makes no difference. Does not happen in an X.org session. Is anybody investigating this?
I believe the error has been re-introduced between 3.0.2 and 3.0.3. https://bugzilla.rpmfusion.org/show_bug.cgi?id=4596#c11
I see. I still think that the real question is, how is a single app able to freeze the entire UI and disable any input?
I tried to extract the problem to a smaller code base: https://github.com/madebr/issues/tree/master/vlc How to simulate the problem: 1. install cmake, make and qt5-devel 2. git clone https://github.com/madebr/issues/tree/master/vlc 3. issues/vlc/run.sh 4. move the mouse cursor, without clicking, over the slider 5. gnome freezes (the run.sh script should unfreeze gnome after 10 seconds) The freeze disappears when you change Qt::ToolTip at https://github.com/madebr/issues/blob/d13d99ec2732ea9e9ad5f98fa04c0d3d46c8086c/vlc/timetooltip.cpp#L36 to Qt::Tool Introduced by https://git.videolan.org/?p=vlc.git;a=commitdiff;h=58155349a053d38d882d47357b225b8703c696ac
(In reply to Alex Grönholm from comment #10) > I see. I still think that the real question is, how is a single app able to > freeze the entire UI and disable any input? It's all explained in downstream bug here https://bugzilla.redhat.com/show_bug.cgi?id=1278159#c36 You can also find several discussions around the various iterations of the patch that landed to mitigate the issue here: https://patchwork.freedesktop.org/series/12340/
I wonder if that MR could help here as well, if you want to give it a try: https://gitlab.gnome.org/GNOME/mutter/merge_requests/168
(In reply to Olivier Fourdan from comment #13) > I wonder if that MR could help here as well, if you want to give it a try: > https://gitlab.gnome.org/GNOME/mutter/merge_requests/168 From my tests here, yes, it does.
Patch for vlc submitted to vlc-devel with an description of the issue: https://mailman.videolan.org/pipermail/vlc-devel/2018-July/120638.html
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. As part of that, we are mass-closing older open tickets in bugzilla.gnome.org which have not seen updates for a longer time (resources are unfortunately quite limited so not every ticket can get handled). If you can still reproduce the situation described in this ticket in a recent and supported software version, then please follow https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines and create a new ticket at https://gitlab.gnome.org/GNOME/mutter/-/issues/ Thank you for your understanding and your help.