Misbehaving launcher plugins freeze shell

[swsnr]

(1) Issue/Bug Description:

A launcher plugin which (due to some internal error perhaps) does not reply to a query event, by simply not writing anything to stdout, freezes the launcher and the entire shell so definitely that (on wayland at least) I had to resort to a SysRq reboot.

I presume the launcher actually runs in-process as part of the shell extension.

I think this is rather dangerous; even a slight error in the communication between a plugin and the launcher can bring down the entire Gnome Shell, which is catastrophic on Wayland where the shell is also the compositor process (arguably a serious design flaw in Gnome, but that's what we've got 🤷 😕 )

Perhaps Pop Shell could move the launcher into a dedicated subprocess? I understand that this may not be possible though, if the launcher needs access to the St toolkit or Gnome Shell API 😕

(2) Steps to reproduce (if you know):

WARNING: After installing the plugin below using the launcher will likely freeze your desktop session!

$ mkdir -p ~/.local/share/pop-shell/broken
$ cat > ~/.local/share/pop-shell/broken/meta.json <<EOF
{
    "name": "broken",
    "description": "Demonstrate broken",
    "pattern": ".*",
    "exec": "broken.py",
    "icon": "dialog-error"
}
EOF
$ ~/.local/share/pop-shell/broken/meta.json <<EOF
import sys
for line in sys.stdin:
  pass
EOF

WARNING: The next steps may leave your system in a state where only a Sysrq reboot or hard reset helps; best use a VM for this!

Logout and login again to make Pop Shell discover the launcher, then type Ctrl+/ and type any text. The shell freezes 💣

(3) Expected behavior:

The shell handles unresponsive launcher plugins gracefully.

(4) Distribution (run cat /etc/os-release):

NAME="Arch Linux"
PRETTY_NAME="Arch Linux"
ID=arch
BUILD_ID=rolling
ANSI_COLOR="38;2;23;147;209"
HOME_URL="https://www.archlinux.org/"
DOCUMENTATION_URL="https://wiki.archlinux.org/"
SUPPORT_URL="https://bbs.archlinux.org/"
BUG_REPORT_URL="https://bugs.archlinux.org/"
LOGO=archlinux

(5) Gnome Shell version:

$ pacman -Qi gnome-shell | head -n3
Name            : gnome-shell
Version         : 1:3.38.3-1
Description     : Next generation desktop shell

(6) Pop Shell version

$ pacman -Qi gnome-shell-extension-pop-shell | head -n3 
Name            : gnome-shell-extension-pop-shell
Version         : 1.2.0-2
Description     : Pop Shell - Tiling window management in Gnome (WIP)

(7) Where was Pop Shell installed from:

https://aur.archlinux.org/packages/gnome-shell-extension-pop-shell

Which essentially comes down to make install:

     make DESTDIR="${pkgdir}/" install
	install -Dm644 schemas/org.gnome.shell.extensions.pop-shell.gschema.xml -t \
		"$pkgdir/usr/share/glib-2.0/schemas"
	install -Dm644 keybindings/*.xml -t \
		"$pkgdir/usr/share/gnome-control-center/keybindings"
    install -Dm755 scripts/configure.sh "${pkgdir}/usr/share/gnome-shell/extensions/pop-shell@system76.com/scripts/configure.sh"

(8) Monitor Setup (2 x 1080p, 4K, Primary(Horizontal), Secondary(Vertical), etc):

Built-in laptop screen:

(9) Other Installed/Enabled Extensions:

$ gnome-extensions list --enabled 
appindicatorsupport@rgcjonas.gmail.com
vscode-search-provider@jomik.org
jetbrains-search-provider@swsnr.de
nasa_apod@elinvention.ovh
native-window-placement@gnome-shell-extensions.gcampax.github.com
pop-shell@system76.com

(10) Other Notes:

I'd like to take the opportunity to give my heartfelt thanks to you for this magnificent extension 🙏 It gives Gnome almost everything I missed from i3, while being so super-easy to setup, and rock-solid (till now it never crashed on me 👏 ) It's a great piece of work and I am very grateful that you give this to the community of Gnome users 🙏

Thank you very much ❤️

[mmstick]

The launcher cannot be its own process, but it can be made async.

[swsnr]

The launcher cannot be its own process, but it can be made async.

I thought so 🤷

That said, all I really care for here is that the launcher doesn't freeze my shell if I make a mistake in the code of my plugin 😬 😇

[swsnr]

I'm coming back to this because I just managed to freeze the shell all over again, this time by synchronously shelling out to zenity --password in response to a submit event. I guess pop shell synchronously waits for the response from the plugin, and thus can't handle input or render windows meanwhile?

Would you perhaps re-classify this as a bug? It's really really easy to lock up the entire shell with what seems to be an entirely legit thing, i.e. starting a dialog input field. Even if it's not supported, I don't think it should freeze the entire shell process catastrophically—mind, on wayland there's no way out of this short of a sysrq reboot.