Bug 1485439 - gnome-keyring-daemon memory leak
Summary: gnome-keyring-daemon memory leak
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: gnome-keyring
Version: rawhide
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Matthias Clasen
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-08-25 17:46 UTC by Tomasz Kłoczko
Modified: 2018-03-09 20:30 UTC (History)
6 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2018-03-09 20:30:14 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)
RSS memory consumption (46.98 KB, image/png)
2017-08-25 17:46 UTC, Tomasz Kłoczko
no flags Details
RSS memory consumption gaph in last 4m1d (45.85 KB, image/png)
2017-12-18 07:18 UTC, Tomasz Kłoczko
no flags Details
/proc/$(pidof /usr/bin/gnome-keyring-daemon)/smaps (252.55 KB, text/plain)
2018-02-24 23:57 UTC, Tim Hughes
no flags Details
/proc/$(pidof /usr/bin/gnome-keyring-daemon)/maps (25.73 KB, text/plain)
2018-02-24 23:58 UTC, Tim Hughes
no flags Details

Description Tomasz Kłoczko 2017-08-25 17:46:21 UTC
Created attachment 1318269 [details]
RSS memory consumption

Something around month ago I've started noticing that gnome-keyring-daemon suddenly starts consuming much more memory.
Because I have on my laptop full zabbix stack and my laptop is powered 24/7 I've started monitoring RSS memory used by gnome-keyring-daemon process.

As you see on the attached graph In last week I was forced two times kill this process to restart it (I just dine it few seconds ago).

Earlier I found one or two times gnome-keyring-daemon RSS bigger than 1.5GB.
As you see on the graph this process suddenly can grow even during the night when I'm doing nothing on GUI session.

Comment 1 Tomasz Kłoczko 2017-12-18 07:16:42 UTC
Short update.
About two months ago memory consumption started improving but still after gnome-keyring-daemon its memory only grows.

Comment 2 Tomasz Kłoczko 2017-12-18 07:18:00 UTC
Created attachment 1369289 [details]
RSS memory consumption gaph in last 4m1d

Comment 3 Fedora End Of Life 2018-02-20 15:23:48 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 28 development cycle.
Changing version to '28'.

Comment 4 Tomasz Kłoczko 2018-02-24 10:05:53 UTC
This bug still is present in rawhide.

Comment 5 Tim Hughes 2018-02-24 23:55:49 UTC
Same issue here. It is using 1.2GB resident



[root@titanium ~]# cat /etc/os-release
NAME=Fedora
VERSION="27 (Workstation Edition)"
ID=fedora
VERSION_ID=27
PRETTY_NAME="Fedora 27 (Workstation Edition)"
ANSI_COLOR="0;34"
CPE_NAME="cpe:/o:fedoraproject:fedora:27"
HOME_URL="https://fedoraproject.org/"
SUPPORT_URL="https://fedoraproject.org/wiki/Communicating_and_getting_help"
BUG_REPORT_URL="https://bugzilla.redhat.com/"
REDHAT_BUGZILLA_PRODUCT="Fedora"
REDHAT_BUGZILLA_PRODUCT_VERSION=27
REDHAT_SUPPORT_PRODUCT="Fedora"
REDHAT_SUPPORT_PRODUCT_VERSION=27
PRIVACY_POLICY_URL="https://fedoraproject.org/wiki/Legal:PrivacyPolicy"
VARIANT="Workstation Edition"
VARIANT_ID=workstation

[root@titanium ~]# /usr/bin/gnome-keyring-daemon --version
gnome-keyring-daemon: 3.20.1
testing: enabled
[root@titanium ~]# rpm -qa|grep keyring
gnome-keyring-3.20.1-3.fc27.x86_64
python2-keyring-10.6.0-1.fc27.noarch
libgnome-keyring-3.12.0-10.fc27.x86_64
gnome-keyring-pam-3.20.1-3.fc27.x86_64
[root@titanium ~]# uname -a
Linux titanium 4.14.16-300.fc27.x86_64 #1 SMP Wed Jan 31 19:24:27 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux


[root@titanium ~]# ps -o pid,%mem,rss,drs,trs,args --pid $(pidof /usr/bin/gnome-keyring-daemon) 
  PID %MEM   RSS   DRS  TRS COMMAND
 1666 15.3 1231668 2652029 998 /usr/bin/gnome-keyring-daemon --daemonize --login


[root@titanium ~]# pstack $(pidof /usr/bin/gnome-keyring-daemon)
Thread 7 (Thread 0x7f689763e700 (LWP 3602)):
#0  0x00007f68c5f99678 in read () at /lib64/libpthread.so.0
#1  0x000055d935fa9c2a in read_all ()
#2  0x000055d935fa9d8a in run_client_thread ()
#3  0x00007f68c6e81486 in g_thread_proxy () at /lib64/libglib-2.0.so.0
#4  0x00007f68c5f8f61b in start_thread () at /lib64/libpthread.so.0
#5  0x00007f68c5cbc98f in clone () at /lib64/libc.so.6
Thread 6 (Thread 0x7f685ffff700 (LWP 28270)):
#0  0x00007f68c5f99678 in read () at /lib64/libpthread.so.0
#1  0x000055d935fa9c2a in read_all ()
#2  0x000055d935fa9d8a in run_client_thread ()
#3  0x00007f68c6e81486 in g_thread_proxy () at /lib64/libglib-2.0.so.0
#4  0x00007f68c5f8f61b in start_thread () at /lib64/libpthread.so.0
#5  0x00007f68c5cbc98f in clone () at /lib64/libc.so.6
Thread 5 (Thread 0x7f686cff9700 (LWP 1623)):
#0  0x00007f68c5f99678 in read () at /lib64/libpthread.so.0
#1  0x000055d935fa9c2a in read_all ()
#2  0x000055d935fa9d8a in run_client_thread ()
#3  0x00007f68c6e81486 in g_thread_proxy () at /lib64/libglib-2.0.so.0
#4  0x00007f68c5f8f61b in start_thread () at /lib64/libpthread.so.0
#5  0x00007f68c5cbc98f in clone () at /lib64/libc.so.6
Thread 4 (Thread 0x7f68c2f80700 (LWP 2221)):
#0  0x00007f68c5cb6bf9 in syscall () at /lib64/libc.so.6
#1  0x00007f68c6e9f50f in g_cond_wait () at /lib64/libglib-2.0.so.0
#2  0x000055d936002c3f in timer_thread_func ()
#3  0x00007f68c6e81486 in g_thread_proxy () at /lib64/libglib-2.0.so.0
#4  0x00007f68c5f8f61b in start_thread () at /lib64/libpthread.so.0
#5  0x00007f68c5cbc98f in clone () at /lib64/libc.so.6
Thread 3 (Thread 0x7f68c3781700 (LWP 1668)):
#0  0x00007f68c5cb03db in poll () at /lib64/libc.so.6
#1  0x00007f68c6e59e99 in g_main_context_iterate.isra () at /lib64/libglib-2.0.so.0
#2  0x00007f68c6e5a232 in g_main_loop_run () at /lib64/libglib-2.0.so.0
#3  0x00007f68c7442b56 in gdbus_shared_thread_func () at /lib64/libgio-2.0.so.0
#4  0x00007f68c6e81486 in g_thread_proxy () at /lib64/libglib-2.0.so.0
#5  0x00007f68c5f8f61b in start_thread () at /lib64/libpthread.so.0
#6  0x00007f68c5cbc98f in clone () at /lib64/libc.so.6
Thread 2 (Thread 0x7f68c3f82700 (LWP 1667)):
#0  0x00007f68c5cb03db in poll () at /lib64/libc.so.6
#1  0x00007f68c6e59e99 in g_main_context_iterate.isra () at /lib64/libglib-2.0.so.0
#2  0x00007f68c6e59fac in g_main_context_iteration () at /lib64/libglib-2.0.so.0
#3  0x00007f68c6e59ff1 in glib_worker_main () at /lib64/libglib-2.0.so.0
#4  0x00007f68c6e81486 in g_thread_proxy () at /lib64/libglib-2.0.so.0
#5  0x00007f68c5f8f61b in start_thread () at /lib64/libpthread.so.0
#6  0x00007f68c5cbc98f in clone () at /lib64/libc.so.6
Thread 1 (Thread 0x7f68c7ddb880 (LWP 1666)):
#0  0x00007f68c5cb03db in poll () at /lib64/libc.so.6
#1  0x00007f68c6e59e99 in g_main_context_iterate.isra () at /lib64/libglib-2.0.so.0
#2  0x00007f68c6e5a232 in g_main_loop_run () at /lib64/libglib-2.0.so.0
#3  0x000055d935f85df5 in main ()

Comment 6 Tim Hughes 2018-02-24 23:57:34 UTC
Created attachment 1400472 [details]
/proc/$(pidof /usr/bin/gnome-keyring-daemon)/smaps

may or may not be useful

Comment 7 Tim Hughes 2018-02-24 23:58:24 UTC
Created attachment 1400473 [details]
/proc/$(pidof /usr/bin/gnome-keyring-daemon)/maps

may or may not be useful

Comment 8 Tomasz Kłoczko 2018-03-09 20:30:14 UTC
I think that this ticket can be closed now.
I don't see any more symptoms of the memory leak in memory usage stats.


Note You need to log in before you can comment on or make changes to this bug.