PSA: Performance bug in Gnome bundled extension Dash to Dock

Bluefin and Aurora
1

Hello,

I noticed some weird performance and power consumption on my laptop and found that I get A LOT of errors in in the system log as follows:

Sep 08 00:12:59 myhost gnome-shell[7630]: JS ERROR: TypeError: dockManager is null
                                          getApps@file:///usr/share/gnome-shell/extensions/dash-to-dock@micxgx.gmail.com/locations.js:1489:9
                                          getRunningApps@file:///usr/share/gnome-shell/extensions/dash-to-dock@micxgx.gmail.com/locations.js:1502:12
                                          get@file:///usr/share/gnome-shell/extensions/dash-to-dock@micxgx.gmail.com/docking.js:1891:59
                                          _syncRunningApplications@resource:///org/gnome/shell/misc/introspect.js:80:26
                                          IntrospectService/<@resource:///org/gnome/shell/misc/introspect.js:43:18
                                          _switchWorkspaceEnd/params.onComplete@resource:///org/gnome/shell/ui/workspaceAnimation.js:512:31
                                          _makeEaseCallback/<@resource:///org/gnome/shell/ui/environment.js:67:13
                                          _easeActorProperty/<@resource:///org/gnome/shell/ui/environment.js:232:60
                                          @resource:///org/gnome/shell/ui/init.js:21:20

In the extension page there is a message on Aug 26th:

unfortunately after a lot of turning extensions on and off i believe that dash to dock is causing a memory leak. Fedora 40, Gnome 46

The author responds on Sept 2:

The leak should have been fixed few days ago by version 95.

I could not install the latest version from the Extension Manager. I believe that the application gets confused due to the extension being a system (not user) deployment.

Fortunately you can simply click the “Install” button in the extension page and choose “GNOME Browser Connector” to open the extension with. After a logout/login I am now using the latest version (96) and so far performance seems to be back to normal:

image
image731Ă—622 53.4 KB

1 Like
2

We’re carrying the stock Fedora package for this. This is an important fix, it should go into Fedora, would you mind filing the issue there?

3 Likes
3

In the meantime I think you can turn off the system extension and install the user one from extensions.gnome.org as a workaround?

EDIT: Nope, couldn’t get that to work.

4

Filed bug for package maintainers with Fedora bugzilla. Hopefuilly it will get picked up.

EDIT: can also confirm that am still getting the errors in journal. Seems to me that it has to do with initialization code that gets invoked anyway even if extension is off?

2 Likes
5

Somewhat unrelated but it seems that to remove a base layer package you should be able to:

rpm-ostree override remove gnome-shell-extension-dash-to-dock-94-1.fc40.noarch

However this results in:

  ostree-image-signed:docker://ghcr.io/ublue-os/bluefin-dx:latest (index: 1)
                   Digest: sha256:dd236b2d3b414d99893daf8b2f18000b2713f8ef9c9ee5316e673db1297db2d9
                  Version: 40.20240907.0 (2024-09-08T04:51:04Z)
               BaseCommit: 1cca1b05dc8abcf1e43764630bd5b7ebc611bb4f779191f2cf0d7a11e729c014
                   Commit: 98a26942e0dfc8297a6e07adaf11a670afdfb8e1ce4d7587dcb78104abec38e3
                StateRoot: default
     InactiveBaseRemovals: gnome-shell-extension-dash-to-dock
          LayeredPackages: oddjob-mkhomedir pwgen sssd-ad sssd-krb5 v4l-utils

Any idea why this would ended up in InactiveBaseRemovals?

6

There is now a build of the new package:

https://koji.fedoraproject.org/koji/buildinfo?buildID=2542985

I downloaded https://kojipkgs.fedoraproject.org//packages/gnome-shell-extension-dash-to-dock/96/1.fc41/noarch/gnome-shell-extension-dash-to-dock-96-1.fc41.noarch.rpm but I have no idea how to install it. I tried:

> rpm-ostree override replace ./gnome-shell-extension-dash-to-dock-96-1.fc41.noarch

error: Non-local replacement overrides not implemented yet

Would be nice to be able to try this out and confirm the fix on the bug report. Any guidance on how to test this?

I guess at worst I would install a Fedora 40 virtual machine and try it there… Would prefer an ostree-based approach to this (so I can try on my own machine).

7

I kicked off a new build: Bluefin Latest · ublue-os/bluefin@0b49d5c · GitHub

When these are done it should pull the fix into bluefin:latest, which you can either test on bare metal or a VM.

1 Like
8

Excuse my ignorance but something seems off. I see the build done and that in versions “latest” is bumped to 40-20240909:

image

Update does not seem to pull it through:

> rpm-ostree update
note: automatic updates (stage) are enabled
Pulling manifest: ostree-image-signed:docker://ghcr.io/ublue-os/bluefin-dx-nvidia:latest
Checking out tree babb57e... done
Enabled rpm-md repositories: updates fedora copr:copr.fedorainfracloud.org:hikariknight:looking-glass-kvmfr google-chrome rpmfusion-nonfree-nvidia-driver rpmfusion-nonfree-steam updates-archive
Importing rpm-md... done
rpm-md repo 'updates' (cached); generated: 2024-09-09T01:14:00Z solvables: 26203
rpm-md repo 'fedora' (cached); generated: 2024-04-14T18:51:11Z solvables: 74881
rpm-md repo 'copr:copr.fedorainfracloud.org:hikariknight:looking-glass-kvmfr' (cached); generated: 2024-08-21T09:46:29Z solvables: 5
rpm-md repo 'google-chrome' (cached); generated: 2024-09-09T14:38:49Z solvables: 3
rpm-md repo 'rpmfusion-nonfree-nvidia-driver' (cached); generated: 2024-09-03T10:07:58Z solvables: 16
rpm-md repo 'rpmfusion-nonfree-steam' (cached); generated: 2024-09-03T10:11:31Z solvables: 2
rpm-md repo 'updates-archive' (cached); generated: 2024-09-07T02:07:26Z solvables: 38774
Resolving dependencies... done
No upgrade available.

I resorted to specifying the 40-20240909 tag specifically with:

rpm-ostree rebase ostree-image-signed:docker://ghcr.io/ublue-os/bluefin-dx-nvidia:40-20240909

Even this does not seem to pull in what I want though?

user@host ~> rpm-ostree status
State: idle
AutomaticUpdates: stage; rpm-ostreed-automatic.timer: no runs since boot
Deployments:
â—Ź ostree-image-signed:docker://ghcr.io/ublue-os/bluefin-dx-nvidia:40-20240909
                   Digest: sha256:b3ee3f767dc0502c56f6439f4c1730e44ee9113c78e211ad5cc999a66648d848
                  Version: 40.20240908.0 (2024-09-09T17:01:54Z)
          LayeredPackages: adcli oddjob-mkhomedir sssd-ad sssd-krb5 touchegg v4l-utils

  ostree-image-signed:docker://ghcr.io/ublue-os/bluefin-dx-nvidia:latest
                   Digest: sha256:b3ee3f767dc0502c56f6439f4c1730e44ee9113c78e211ad5cc999a66648d848
                  Version: 40.20240908.0 (2024-09-09T17:01:54Z)
          LayeredPackages: adcli oddjob-mkhomedir sssd-ad sssd-krb5 touchegg v4l-utils

user@host ~> rpm-ostree rebase ostree-image-signed:docker://ghcr.io/ublue-os/bluefin-dx-nvidia:40-20240909
error: Old and new refs are equal: ostree-image-signed:docker://ghcr.io/ublue-os/bluefin-dx-nvidia:40-20240909

user@host ~ [1]> rpm -qa | grep dash-to-dock
gnome-shell-extension-dash-to-dock-94-1.fc40.noarch
user@host ~>

How do I force an update to that build? Is there a way to select it via the sha256sum?

9

You’re on the right image, it looks like rebuilding it didn’t pull in the new version. I’m on a trip so don’t have time to dig deep but maybe tomorrow’s build will just pick it up. I’ll keep checking.

2 Likes
10

This topic was automatically closed 12 hours after the last reply. New replies are no longer allowed.

12

This got pulled into mine this morning on bluefin:stable:

gnome-shell-extension-dash-to-dock 92-1.fc40 -> 94-1.fc40

There’s some nvidia breakage though so we’ll need to keep retrying those over the next few days.

1 Like
13

I’m guessing a lot more people will see the issue now that it’s in stable…

The fix is in version 96-1.fc40. This is now in fedora 40 testing repositories.

14

Ah understood, I was off by 2. Yeah we’ll have to wait.

It’d be awesome if Fedora published testing images of incoming fixes so we could generate testing builds, maybe some day. :smile:

15

performance bug still here…

16

Just to recap

  • The problem is in gnome-shell-extension-dash-to-dock-94-1.fc40.noarch
  • This was in :latest branch so I saw it first (running latest)
  • It made its way to :stable a couple of days ago, so now more people may observe it
  • It is fixed in gnome-shell-extension-dash-to-dock 96-1.fc40 which is currently in Fedora testing

If you are getting this, what I have done is disable the extension and logout/login (to unload it). If it is enabled at login, simply turning it off doesn’t help.

I will update when this makes its way to :latest but currently using a VM of Fedora 40 with the testing package works fine, so it’s simply a matter of waiting…

17

Looks like this has been push to the stable repo on Fedora side:

FEDORA-2024-192747c8e6 (gnome-shell-extension-dash-to-dock-96-1.fc40) has been pushed to the Fedora 40 stable repository.

I hope this means it will soon make its way to Bluefin latest (and then stable)?

1 Like
18

I pushed a new build, lets see if it gets picked up: Bluefin Latest · ublue-os/bluefin@d02a945 · GitHub

19

gnome-shell-extension-dash-to-dock 94-1.fc40 → 96-1.fc40

Alright! I’ll push out a new stable build now, nvidia builds are red today though, so it’ll take a bit for those to sort out.

2 Likes
20

This topic was automatically closed 24 hours after the last reply. New replies are no longer allowed.