CRASH/FREEZE in Activities Overview in GNOME Shell 41.1 (ui/windowPreview.js: TypeError: app is null)
- openSUSE Tumbleweed, fully updated.
- Kernel: 5.14.14-1-default
- gnome-shell 41.1, released 4 days ago, but it has been happening ever since GNOME 40 back in April for me.
- XOrg. I don't use Wayland (NVIDIA).
- It happens with GNOME Extensions 100% DISABLED. On a totally unmodified GNOME.
- When the Activities overview opens up, there's a risk that GNOME Shell completely freezes with a blank, gray background.
- No workspace/wallpapers are drawn.
- No application previews are drawn.
- It is completely blank, and doesn't respond to any clicks.
- The only thing that works is Alt-F2 and "r" to restart gnome-shell.
Steps to reproduce
- Open Activities overview. Either with the super key or the hot corner.
- Sometimes GNOME Shell freezes. It's erratic. It looks exactly like a race condition/timing issue, because there is no pattern to when it happens.
Relevant logs, screenshots, screencasts etc.
I have been investigating this every time it happens, and may have finally found the cause.
Whenever the crash/freeze happens, I press Ctrl-Alt-F3 to switch to an interactive terminal while gnome-shell remains frozen.
I then run this command to look at the latest logging output from gnome-shell:
journalctl -r /usr/bin/gnome-shell
During the latest two or three crashes, I started noticing that I always saw the following error messages in the log when the crash happens:
Nov 08 23:49:06 aurora gnome-shell: gvc_mixer_ui_device_get_id: assertion 'GVC_IS_MIXER_UI_DEVICE (device)' failed Nov 08 23:49:06 aurora gnome-shell: Couldn't match the portless stream (with card) - 'Scarlett 18i8 Multichannel' is it an input ? -> 1, streams card id -> 46 Nov 08 23:48:38 aurora gnome-shell: g_signal_handler_disconnect: assertion 'handler_id > 0' failed Nov 08 23:48:38 aurora gnome-shell: JS ERROR: Exception in callback for signal: trigger: TypeError: app is null _init@resource:///org/gnome/shell/ui/windowPreview.js:125:9 _addWindowClone@resource:///org/gnome/shell/ui/workspace.js:1392:21 _init@resource:///org/gnome/shell/ui/workspace.js:1130:22 _updateWorkspaces@resource:///org/gnome/shell/ui/workspacesView.js:462:29 _init@resource:///org/gnome/shell/ui/workspacesView.js:121:14 _updateWorkspacesViews@resource:///org/gnome/shell/ui/workspacesView.js:1091:24 prepareToEnterOverview@resource:///org/gnome/shell/ui/workspacesView.js:1039:14 animateToOverview@resource:///org/gnome/shell/ui/overviewControls.js:680:33 animateToOverview@resource:///org/gnome/shell/ui/overview.js:82:24 _animateVisible@resource:///org/gnome/shell/ui/overview.js:540:24 show@resource:///org/gnome/shell/ui/overview.js:525:14 toggle@resource:///org/gnome/shell/ui/overview.js:633:18 _toggleOverview@resource:///org/gnome/shell/ui/layout.js:1191:27 _emit@resource:///org/gnome/gjs/modules/core/_signals.js:114:47 _trigger@resource:///org/gnome/shell/ui/layout.js:1324:14 _onBarrierHit@resource:///org/gnome/shell/ui/layout.js:1366:18 Nov 08 23:48:13 aurora gnome-shell: Window manager warning: WM_TRANSIENT_FOR window 0x5400325 for 0x540032a window override-redirect is an override-redirect window and this is not correct according to the standard, so we'll fallback to the first non-override-redirect window 0x5400006. Nov 08 23:47:36 aurora gnome-shell: ../gobject/gsignal.c:2732: instance '0x55e74631e9d0' has no handler with id '327457' Nov 08 23:46:46 aurora gnome-shell: Failed to set the markup of the actor '<unnamed>[<ClutterText>:0x55e758e68890]': Error on line 1: Entity did not end with a semicolon; most likely you used an ampersand character without intending to start an entity — escape ampersand as & Nov 08 23:46:45 aurora gnome-shell: Received error from D-Bus search provider firefox.desktop: Gio.DBusError: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name org.mozilla.Firefox.SearchProvider was not provided by any .service files Nov 08 23:46:45 aurora gnome-shell: Received error from D-Bus search provider firefox.desktop: Gio.DBusError: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name org.mozilla.Firefox.SearchProvider was not provided by any .service files
I also noticed that the "GVC_IS_MIXER_UI_DEVICE" message seemed to always happen during the crash the last times, so I wanted to look at the historical data compared to the "TypeError: app is null" error:
journalctl -r /usr/bin/gnome-shell | grep "GVC_IS_MIXER_UI_DEVICE" | wc -l journalctl -r /usr/bin/gnome-shell | grep "TypeError: app is null" | wc -l
The result is:
GVC_IS_MIXER_UI_DEVICEoccurs 108 times.
TypeError: app is nulloccurs 33 times.
I have not had 108 crashes -- mainly because I stopped using Linux and used Windows instead for nearly half a year due to these GNOME overview crashes, just assuming that they were "GNOME 40 fresh release related". So that rules out the mixer error.
However, 33 crashes sounds extremely accurate. So I am willing to bet that the
TypeError: app is null is the actual crash that is breaking the Activities Overview.
I was reading through older issues with similar things, where code was crashing Activities Overview and giving the same "gray/empty overview" screen, and those were due to things like "getLastWorkspace().doSomething()" without verifying that getLastWorkspace was non-null first. Those exceptions threw an error and caused the same symptoms.
Is it possible that my report is the same kind of bug? It seems like the activities overview is fetching a list of apps, and in some certain conditions (it seems race condition/timing related), one of the "apps" that it retrieves is null instead of being data about the app. And therefore crashing the overview. That's the best theory I have...
All I can add is that I have not been closing applications just as the overview opens. So I am not responsible for "app suddenly being null". It's something inside GNOME Shell or related OS components. It might be a rare, general failure to retrieve data about the currently running applications. So I am not sure it should be patched by just doing "if app is null, skip it". Maybe there's a deeper issue here about retrieving app data.
When this happens again, I will keep looking at the logs to see if the error message is still the same. So far, the past 2-3 crashes (since I began checking logs) have all had the TypeError message.
Let me know if there's any other data or logs I can collect to help.
With best regards, Johnny