Skip to content

WIP: ShellApp: Defend against running_state->windows being empty

Simon McVittie requested to merge smcv/gnome-shell:wip/app-empty-window-list into main

Previously, it was treated as an invariant that whenever app->running_state was non-NULL, app->running_state->windows was also non-NULL.

However, on #750 (closed) and #822 (closed), we see that the backtraces for GNOME Shell 3.30.x contain _shell_app_remove_window() line 1110. In 3.30.x, that line is at a point in _shell_app_remove_window() where the app->running_state->windows invariant does not hold: window has already been removed from app->running_state->windows, but app->running_state has not yet been cleared. (The same applies in 3.32.x, but with different line numbers.)

Signed-off-by: Simon McVittie smcv@debian.org Closes: #750 (closed) Closes: #822 (closed)

Currently untested. I'm hoping this is a solution to https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=926212; any maintainer opinions?

It still seems wrong that last-unref for a ShellApp can occur during _shell_app_remove_window(), so maybe _shell_app_remove_window() should also hold a ref for the duration, or maybe the connection to shell_app_on_unmanaged() should be using g_signal_connect_object() to keep the object alive for the duration of the signal handler? Otherwise I think we'll get GLib assertions while emitting WINDOWS_CHANGED from an object that was already disposed and possibly freed.

/cc @bernhardu

Merge request reports