GNOME Bugzilla – Bug 776041
EasyScreenCast extension causes frozen login on Wayland, needs core dev debugging skills
Last modified: 2021-07-05 14:42:12 UTC
The EasyScreenCast extension [1] causes a frozen login screen for Wayland session every(?) time the gstreamer cache [2] is touched. A simple reproducer is provided in: https://bugzilla.redhat.com/show_bug.cgi?id=1394755#c22 (A journal snippet is provided in comment 0.) I understand you'll want to say "this is the extension problem, not ours", but I believe this needs a core gnome-shell dev attention, because extension authors are not likely to be able to debug this. This only happens for Wayland sessions, not X11, which indicates it could be a problem in gnome-shell itself. It can also be a problem in gstreamer, in which case it would be great if you could provide a reproducer (methods called) which I could then provide to gstreamer developers. Also, it would be great if gnome-shell could somehow safeguard against such issues in the future, to disable the extension and continue, instead of showing just a frozen screen. Moreover, this extension is quite popular for QA, so fixing this helps us file better bug reports in the future. That's my closing pitch :-) Thanks. gnome-shell-3.22.2-2.fc25.x86_64 EasyScreenCast@iacopodeenosee.gmail.com version 34 [1] https://extensions.gnome.org/extension/690/easyscreencast/ [2] ~/.cache/gstreamer-1.0/registry.x86_64.bin
This is a deadlock caused by gst_init() in the compositor process refreshing the registry and the forked gst-plugin-scanner process loading all plugins. In particular libgstclutter initializes clutter which by default initializes its gdk backend which by default opens a wayland client connection and... deadlock. The gnome-shell extension triggers this because it does Gst.init() on startup, but even without the extension it can be easily reproduced by deleting the gstreamer cache file, starting a wayland gnome session and entering imports.gi.Gst.init(null) on gnome-shell's looking glass (Alt+F2, "lg") or just starting a normal recording with the default keybinding ctrl+alt+shift+R . The only sane way forward is to stop using gstreamer in the compositor which is in the plans. For the record, the deadlocked stack traces are: gnome-shell process:
+ Trace 236976
[ the stack traces again, trying to work around bugzilla's pretty printer ] =================== gnome-shell process ===================
+ Trace 236977
[ *sigh*, I give up, it's not that important either ]
Thanks a lot, Rui, for debugging this. Is there any recommendation I can give to EasyScreenCast authors in the meantime to work around this? Can they call gst_init() later, and at what point?
A possible solution to the issue is in this merge request. Sanity checks and testing would be greatly appreciated: https://github.com/EasyScreenCast/EasyScreenCast/pull/148
*** Bug 777059 has been marked as a duplicate of this bug. ***
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/gnome-shell/-/issues/ Thank you for your understanding and your help.