Unlock takes a long time

[Roger Lipscombe]

I searched and found related bugs #1774188 and #1847566, but one of those is against 19.04, which is end-of-support, and the other was abandoned with no feedback from the OP. So, let's try again.

When unlocking my screen, it takes progressively longer to unlock. After a fresh restart, it's pretty quick. After about a day, it takes about a second. After a longer period, it takes up to 5 seconds.

When I press Enter at the lock screen to get to the password entry, the "wipe" effect commonly stalls as it gets near the top of the screen; not sure if this is related.

After correctly entering my password, it takes several seconds before my desktop is visible. It's _there_, because moving the mouse around changes the mouse pointer according to what's under it (e.g. it turns into an I-bar on the Firefox search/address box and a finger icon on a link). It just takes several seconds to actually draw the screen.

ProblemType: Bug
DistroRelease: Ubuntu 18.04
Package: gnome-shell 3.28.4-0ubuntu18.04.3
ProcVersionSignature: Ubuntu 5.3.0-42.34~18.04.1-generic 5.3.18
Uname: Linux 5.3.0-42-generic x86_64
NonfreeKernelModules: nvidia_modeset nvidia
ApportVersion: 2.20.9-0ubuntu7.12
Architecture: amd64
CurrentDesktop: ubuntu:GNOME
Date: Sun Mar 29 11:10:07 2020
DisplayManager: gdm3
EcryptfsInUse: Yes
InstallationDate: Installed on 2020-01-10 (78 days ago)
InstallationMedia: Ubuntu 18.04.3 LTS "Bionic Beaver" - Release amd64 (20190805)
SourcePackage: gnome-shell
UpgradeStatus: No upgrade log present (probably fresh install)

[Daniel van Vugt (vanvugt)]

Since we find so many bugs are caused by extensions we first need you to uninstall all of these:

'audio-output-switcher@anduchs',
'<email address hidden>',
'multi-monitors-add-on@spin83',
'<email address hidden>'

Be sure to uninstall them and don't just disable them because a disabled extension can still interfere with the shell.

[Roger Lipscombe (8-roger)]

I can't do that on my primary PC -- I'm *using* those extensions.

I'll set up my spare PC the same way (with the extensions) and see if I can repro. Then I'll disable them and see if the problem goes away (or not).

Gonna take me about a week, though, since this only happens after a bunch of locking and unlocking.

[Roger Lipscombe (8-roger)]

Some investigation and notes (and apologies for the noise; I need somewhere to take notes):

I have the following extensions in /usr/share/gnome-shell/extensions:

<email address hidden>/
<email address hidden>/
<email address hidden>/
<email address hidden>/
<email address hidden>/
<email address hidden>/
<email address hidden>/
<email address hidden>/
<email address hidden>/
<email address hidden>/
multi-monitors-add-on@spin83/
<email address hidden>/
<email address hidden>/
<email address hidden>/
<email address hidden>/
TaskBar@zpydr/
<email address hidden>/
<email address hidden>/
<email address hidden>/
<email address hidden>/
<email address hidden>/
<email address hidden>/

I have the following extensions installed via apt (reason, where known):

gnome-shell-extension-appindicator (ubuntu-desktop)
gnome-shell-extension-autohidetopbar (explicit)
gnome-shell-extension-dashtodock (explicit)
gnome-shell-extension-dash-to-panel (explicit)
gnome-shell-extension-mediaplayer (explicit)
gnome-shell-extension-move-clock (explicit)
gnome-shell-extension-multi-monitors (explicit)
gnome-shell-extension-pixelsaver (explicit)
gnome-shell-extensions (explicit)
gnome-shell-extension-taskbar (explicit)
gnome-shell-extension-ubuntu-dock (ubuntu-desktop)
ubuntu-session (ubuntu-desktop)

I'm trying to figure out which directory maps to which .deb package, and then I'll remove the extensions that I'm not using. If that solves the problem: job done.

I also have the following extensions installed in ~/.local/share/gnome-shell/extensions:

<email address hidden>/
<email address hidden>/
multi-monitors-add-on@spin83/
audio-output-switcher@anduchs/
<email address hidden>/

I'm not sure what it means that I have an extension listed in both locations.

I've removed the dashtodock and pixelsaver extensions; I wasn't using them. I'll remove some more unused extensions if that doesn't solve the problem.

Concurrently, I'll leave my other PC nearly stock and I'll lock/unlock it a bunch of times over the next week or so and see if it gets slower.

[Roger Lipscombe (8-roger)]

I've also removed gnome-shell-extension-move-clock, gnome-shell-extension-autohidetopbar and gnome-shell-extension-taskbar.

> I'm not sure what it means that I have an extension listed in both locations.

I suspect that either I've installed it explicitly, or extensions.gnome.org installed an update.

[Roger Lipscombe (8-roger)]

Update: my spare PC is definitely getting slower at unlocking, but (possibly because I'm not using it as much) not as quickly.

Are there any logs/debug steps you want me to run on it? I know enough gdb to be dangerous, if that helps.

[Daniel van Vugt (vanvugt)]

If the problem gets worse over time then it might be memory related. Please run:

  ps auxw | grep gnome-shell

and tell us what you see when it is (a) fast and (b) slow.

If that's the problem then it is likely an extension is to blame. So make sure you have uninstalled ALL of them, at least temporarily as a test.

[Roger Lipscombe (8-roger)]

With ALL extensions, it doesn't get slower. When it was getting slower, I had the standard 'gnome-shell-extensions' package installed.

I'm going to reinstall it and see if that reproduces the problem.

[Roger Lipscombe (8-roger)]

That should say "With ALL extensions uninstalled..."

[Roger Lipscombe (8-roger)]

This is proving to be really difficult to reproduce -- it's getting slower (but really slowly) on my spare PC. The memory use for gnome-shell is, essentially, static.

So: I sampled some perf data from the PC where it consistently happens and threw up a flame graph.

It spends a bunch of time in 'clutter_actor_destroy' -> 'destroy_closure_array' -> 'handler_lookup'.

This suggests to me that some extension or other is registering a handler for something multiple times, and not cleaning it up, which means it takes longer and longer to iterate through the list of handlers.

I'm gonna have a rummage through the source code to see which function adds handlers, and then I'll attach a debugger to it to see if something's leaking registered handlers.

[Roger Lipscombe (8-roger)]

> see if something's leaking registered handlers.

It looks like clutter handlers are stored in two different hash tables: g_handlers and g_handler_list_bsa_ht.

On the PC that's really slow, g_handlers.size = 8388608 (that's ~8M); on the PC that's not, g_handlers.size = 65536 (~65K). So, yeah, something's leaking, afaict.

Gonna see if the hash table entries (signal_id, instance, closure) point to anything that gives me a clue. Given that the extensions are written mostly in JS, this is gonna be all kinds of interesting...

[Roger Lipscombe (8-roger)]

See https://github.com/home-sweet-gnome/dash-to-panel/issues/959, wherein I discover that dash-to-panel seems to be the worst offender in terms of leaking handlers, but there's a lower-grade steady leak anyway, which might bear looking at.

[Daniel van Vugt (vanvugt)]

Upstream says the fix is in v37, which we already have in Ubuntu 20.10.