After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 728369 - gnome-shell uses 100% CPU when starting rhythmbox
gnome-shell uses 100% CPU when starting rhythmbox
Status: RESOLVED FIXED
Product: gnome-shell
Classification: Core
Component: general
3.12.x
Other Linux
: Normal normal
: ---
Assigned To: gnome-shell-maint
gnome-shell-maint
Depends on:
Blocks:
 
 
Reported: 2014-04-16 18:43 UTC by adria.arrufat
Modified: 2017-01-18 15:29 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Screenshot showing how CPU is used and the dbus-daemon command line (171.92 KB, image/png)
2014-04-16 18:43 UTC, adria.arrufat
Details

Description adria.arrufat 2014-04-16 18:43:36 UTC
Created attachment 274515 [details]
Screenshot showing how CPU is used and the dbus-daemon command line

This bug has been introduced in GNOME 3.12

Whenever I start rhythmbox, it takes around 1-2 minutes to start, in which both gnome-shell and rhythmbox are using 100% CPU.
(during those loading minutes rhythmbox is unresponsive and doesn't show any tracks)

dbus-daemon is using 50% CPU while rhythmbox loads and has been started automatically with the following command line:
/usr/bin/dbus-daemon --config-file0/etc/at-spi2/accessibility.conf --nofork --print-addres 3

Once rhythmbox has finished loading, it uses ~300 MB RAM instead of the usual 90 MB it used in GNOME 3.10

I noticed I had the same issue in 3.10 whenever I had an accessibility feature enabled, such as caribou.

I tried removing configuration files, dconf settings and rebuilding both gnome-shell and rhythmbox without success.

I'm using gnome packages from arch linux.

The screenshot attached displays the CPU usage while loading rhythmbox and the dbus-daemon command line.
Comment 1 Milan Bouchet-Valat 2014-04-20 17:11:50 UTC
See also Bug 728319 (same issue seen from the other side).