Ubuntu
gnome-keyring package

gnome-keyring-daemon hogs CPU

Bug #858775 reported by Ilkka Laukkanen
124
This bug affects 27 people
Affects Status Importance Assigned to Milestone
gnome-keyring (Ubuntu)
Confirmed
Low
Unassigned

Bug Description

I just upgraded my Nokia Booklet to Oneiric, and noticed that gnome-keyring-daemon is using about 40% CPU all the time.

Here's a snippet from strace:
time(NULL) = 1316942473
times({tms_utime=10433, tms_stime=907, tms_cutime=112, tms_cstime=7}) = 1718106444
gettimeofday({1316942473, 940560}, NULL) = 0
getrusage(RUSAGE_SELF, {ru_utime={104, 338520}, ru_stime={9, 72567}, ...}) = 0
time(NULL) = 1316942473
times({tms_utime=10433, tms_stime=907, tms_cutime=112, tms_cstime=7}) = 1718106444
gettimeofday({1316942473, 941462}, NULL) = 0
getrusage(RUSAGE_SELF, {ru_utime={104, 338520}, ru_stime={9, 72567}, ...}) = 0
time(NULL) = 1316942473
times({tms_utime=10433, tms_stime=907, tms_cutime=112, tms_cstime=7}) = 1718106444
gettimeofday({1316942473, 942363}, NULL) = 0
getrusage(RUSAGE_SELF, {ru_utime={104, 338520}, ru_stime={9, 72567}, ...}) = 0
time(NULL) = 1316942473
times({tms_utime=10433, tms_stime=907, tms_cutime=112, tms_cstime=7}) = 1718106444
gettimeofday({1316942473, 943249}, NULL) = 0
getrusage(RUSAGE_SELF, {ru_utime={104, 342521}, ru_stime={9, 72567}, ...}) = 0
time(NULL) = 1316942473
times({tms_utime=10434, tms_stime=907, tms_cutime=112, tms_cstime=7}) = 1718106444
gettimeofday({1316942473, 944096}, NULL) = 0
getrusage(RUSAGE_SELF, {ru_utime={104, 342521}, ru_stime={9, 72567}, ...}) = 0
time(NULL) = 1316942473
times({tms_utime=10434, tms_stime=907, tms_cutime=112, tms_cstime=7}) = 1718106444
gettimeofday({1316942473, 944909}, NULL) = 0
getrusage(RUSAGE_SELF, {ru_utime={104, 342521}, ru_stime={9, 72567}, ...}) = 0

It seems to be spinning within dbus_connection_dispatch, I'll see if I can come up with a backtrace.

gnome-keyring is version 3.1.92-0ubuntu1.

The system differs from a normal Oneiric install in one regard: for some reason I can't get gdm to start on login, so it actually boots into a console and I "sudo start gdm" from there. Don't know if it affects anything.

Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in gnome-keyring (Ubuntu):
status: New → Confirmed
Revision history for this message
Luke Dixon (dixonl90) wrote :

I have the same issue but gdm works just fine for me (clean install). gnome-keyring-daemon uses almost 100% cpu for about 10 seconds before stopping. It never used to do this.

Revision history for this message
Jendrik Seipp (jendrikseipp) wrote :

This still happens in Precise.

Revision history for this message
mobrien118 (mobrien118) wrote :

This happens to me when I load Google-Chrome. Once it loads, it asks me for my password to unlock the keyring, the it's off to the races!

It doesn't seem to ever stop using 100% CPU (on my 3.4GHz Pentium D).

If I kill it, everything seems fine.

I have a fully updated Precise installation.

Is this the same issue? Has anyone found a workaround? Solution? Is there anything I can do to help?

Revision history for this message
Sebastien Bacher (seb128) wrote :

Thank you for taking the time to report this bug and helping to make Ubuntu better. The issue you are reporting is an upstream one and it would be nice if somebody having it could send the bug to the developers of the software by following the instructions at https://wiki.ubuntu.com/Bugs/Upstream/GNOME. If you have done so, please tell us the number of the upstream bug (or the link), so we can add a bugwatch that will inform us about its status. Thanks in advance.

Changed in gnome-keyring (Ubuntu):
importance: Undecided → Low
Jendrik Seipp (jendrikseipp)
summary: - gnome-keyring-daemon hogs CPU in Oneiric
+ gnome-keyring-daemon hogs CPU
Revision history for this message
Bernie Innocenti (codewiz) wrote :

I'm also seeing this bug on Precise with gnome-keyring_3.2.2-2ubuntu4 and libgcrypt11_1.5.0-3ubuntu0.1.

I could get a stack trace, but unfortunately without debug symbols:

#0 0x00007ffff673eb4a in times () from /lib/x86_64-linux-gnu/libc.so.6
#1 0x00007ffff672e47a in clock () from /lib/x86_64-linux-gnu/libc.so.6
#2 0x00007ffff6c8ec73 in ?? () from /lib/x86_64-linux-gnu/libgcrypt.so.11
#3 0x00007ffff6c8facd in ?? () from /lib/x86_64-linux-gnu/libgcrypt.so.11
#4 0x00007ffff6c621a0 in ?? () from /lib/x86_64-linux-gnu/libgcrypt.so.11
#5 0x00007ffff6c62d4e in ?? () from /lib/x86_64-linux-gnu/libgcrypt.so.11

After I installed the dbg package, the process was no longer stuck. Perhaps it was just stuck in a very long computation.

Revision history for this message
Bernie Innocenti (codewiz) wrote :

Happened again, this time I had some debug info:

#0 0x00007ffff673eb4a in times () from /lib/x86_64-linux-gnu/libc.so.6
#1 0x00007ffff672e47a in clock () from /lib/x86_64-linux-gnu/libc.so.6
#2 0x00007ffff6c8ec73 in do_fast_random_poll () at random-csprng.c:1244
#3 0x00007ffff6c8facd in _gcry_rngcsprng_fast_poll () at random-csprng.c:1270
#4 0x00007ffff6c621a0 in md_open (h=0x7fffffffdf58, algo=1, secure=0, hmac=0) at md.c:503
#5 0x00007ffff6c62d4e in _gcry_md_hash_buffer (algo=1, digest=0x7fffffffdf90, buffer=0xc1d070, length=0) at md.c:1037

Revision history for this message
Bernie Innocenti (codewiz) wrote :
Download full text (5.2 KiB)

I can reproduce it at will by relaunching Chromium.

Here's a better stack trace with all threads:

~$ sudo ./dstack gnome-keyring-daemon
Process ID: 8460
Program name: gnome-keyring-d
Program path: /usr/bin/gnome-keyring-daemon
Thread count: 6

Dstack of gnome-keyring-d pid 8460 (/usr/bin/gnome-keyring-daemon)

[Switching to thread 1 (Thread 0x7ffff7fc3800 (LWP 8460))]
#0 0x00007ffff673eb4a in times () from /lib/x86_64-linux-gnu/libc.so.6
#0 0x00007ffff673eb4a in times () from /lib/x86_64-linux-gnu/libc.so.6
#1 0x00007ffff672e47a in clock () from /lib/x86_64-linux-gnu/libc.so.6
#2 0x00007ffff6c8ec73 in do_fast_random_poll () at random-csprng.c:1244
#3 0x00007ffff6c8facd in _gcry_rngcsprng_fast_poll () at random-csprng.c:1270
#4 0x00007ffff6c621a0 in md_open (h=0x7fffffffe258, algo=1, secure=0, hmac=0) at md.c:503
#5 0x00007ffff6c62d4e in _gcry_md_hash_buffer (algo=1, digest=0x7fffffffe290, buffer=0x16ec980, length=13) at md.c:1037
#6 0x000000000045267b in ?? ()
#7 0x0000000000453287 in ?? ()
#8 0x0000000000455ea3 in ?? ()
#9 0x0000000000456391 in ?? ()
#10 0x0000000000451744 in ?? ()
#11 0x0000000000487d75 in ?? ()
#12 0x000000000044ad8c in ?? ()
#13 0x000000000042ea44 in ?? ()
#14 0x00007ffff7bbff06 in ?? () from /usr/lib/libgck-1.so.0
#15 0x00007ffff7bc7403 in gck_object_destroy () from /usr/lib/libgck-1.so.0
#16 0x000000000041c90f in ?? ()
#17 0x0000000000413506 in ?? ()
#18 0x0000000000414ade in ?? ()
#19 0x00007ffff70ec9a6 in dbus_connection_dispatch () from /lib/x86_64-linux-gnu/libdbus-1.so.3
#20 0x000000000049ce55 in ?? ()
#21 0x00007ffff7369d53 in g_main_context_dispatch () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#22 0x00007ffff736a0a0 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#23 0x00007ffff736a49a in g_main_loop_run () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#24 0x000000000040f041 in ?? ()
#25 0x00007ffff66a276d in __libc_start_main () from /lib/x86_64-linux-gnu/libc.so.6
#26 0x000000000040f349 in ?? ()
#27 0x00007fffffffec58 in ?? ()
#28 0x000000000000001c in ?? ()
#29 0x0000000000000003 in ?? ()
#30 0x00007fffffffee4c in ?? ()
#31 0x0000000000000000 in ?? ()

[Switching to thread 2 (Thread 0x7ffff21cf700 (LWP 10403))]
#0 0x00007ffff6ecfd2d in read () from /lib/x86_64-linux-gnu/libpthread.so.0
#0 0x00007ffff6ecfd2d in read () from /lib/x86_64-linux-gnu/libpthread.so.0
#1 0x0000000000440e7b in ?? ()
#2 0x0000000000446ca1 in ?? ()
#3 0x00007ffff738b9e5 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#4 0x00007ffff6ec8e9a in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0
#5 0x00007ffff67734bd in clone () from /lib/x86_64-linux-gnu/libc.so.6
#6 0x0000000000000000 in ?? ()

[Switching to thread 3 (Thread 0x7ffff29d0700 (LWP 8573))]
#0 0x00007ffff6767b03 in poll () from /lib/x86_64-linux-gnu/libc.so.6
#0 0x00007ffff6767b03 in poll () from /lib/x86_64-linux-gnu/libc.so.6
#1 0x00007ffff736a036 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#2 0x00007ffff736a49a in g_main_loop_run () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#3 0x00007ffff792f406 in ?? () from /usr/lib/x86_64-linux-gnu/libgio-2.0.so.0
#4 0x00007ffff738b9e5 in ?? () from /lib/x86_64-linux-gnu/libglib-2....

Read more...

Revision history for this message
Janusz (yorashtan2) wrote :

This bug was causing my laptop (Thinkpad T500) to overheat within 5 minutes every time I started chrome. I've bought a cooling pad but it's not helping (the laptop still shuts itself).

I've found out that the issue does not come up when Google Chrome is not connected with a Google account. In other words, as a temporary workaround, one can log out of synchronisation. I don't see gnome-keyring-daemon hogging CPU any more with this option turned off.

Revision history for this message
Jani Uusitalo (uusijani) wrote :

Just making a note about similarity between this and bug #939301; latter perhaps a duplicate?

Revision history for this message
mikel (mikel-martin) wrote :

This happens to me with google chrome, but not with chromiun-browser.

If i make sure all google chrome processes are killed and restart gnome-keyring-d, it doesn't happen any more.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.
Subscribing...

Other bug subscribers

Related questions

Remote bug watches

Bug watches keep track of this bug in other bug trackers.