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 609599 - memory leak in gnome-settings-daemon
memory leak in gnome-settings-daemon
Status: RESOLVED INCOMPLETE
Product: gnome-settings-daemon
Classification: Core
Component: background
2.28.x
Other Linux
: Normal major
: ---
Assigned To: gnome-settings-daemon-maint
gnome-settings-daemon-maint
Depends on:
Blocks:
 
 
Reported: 2010-02-10 23:38 UTC by amcnabb
Modified: 2011-02-03 10:28 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description amcnabb 2010-02-10 23:38:51 UTC
As reported in Redhat's bugzilla:

https://bugzilla.redhat.com/show_bug.cgi?id=558596

Since upgrading to Fedora 12, I've noticed a memory leak in
gnome-settings-daemon.  It appears that when I change the background image with
gconftool-2 (/desktop/gnome/background/picture_filename), gnome-settings-daemon
never frees the old image.  If I stay logged in for a few weeks, I've seen
gnome-settings-daemon using over 6 GB of resident memory.

The currently installed version of gnome-settings-daemon is
gnome-settings-daemon-2.28.1-10.fc12.x86_64.

I applied spanned-background.patch (attached to bug #603551) and set
/desktop/gnome/background/picture_options to "spanned".  When I change the
background image, there is no longer a memory leak.

This convinces me that per-monitor-background.patch is the source of the memory
leak.
Comment 1 Bastien Nocera 2010-12-07 16:06:36 UTC
As per downstream bug, got fixed in Fedora 13 (so GNOME 2.30).
Comment 2 amcnabb 2010-12-07 18:12:42 UTC
Umm, the downstream bug did not say this was fixed; it just said that nobody ever looked at it so it was getting automatically closed.  There's a big difference.
Comment 3 Bastien Nocera 2010-12-07 18:15:43 UTC
https://bugzilla.redhat.com/show_bug.cgi?id=558596#c5:
"
Andrew McNabb 2010-09-14 16:04:32 EDT
This appears to have been fixed in Fedora 13.
"

Oh, snap.
Comment 4 amcnabb 2010-12-07 19:31:52 UTC
I used the vague word "appears" because it was really hard to try to reproduce a bug 7 or 8 months later, especially after I had found a workaround.  I spent about 5 minutes trying to go back to look at it and didn't seem to see the problem.  I'm not trying to be disagreeable--it's just really hard to be motivated to help report and track down bugs when no one seems to care.
Comment 5 Bastien Nocera 2010-12-08 12:09:04 UTC
So the bug isn't fixed? If it isn't, then it would be nice if you could give exact steps on how to reproduce the problem.

Is it only gnome-settings-daemon, or nautilus grows in memory as well? Are you able to see the problem when launching /usr/libexec/gnome-settings-daemon by hand and running it under valgrind for example (you'll need to kill the existing instance and pass the appropriate flags for it not to go in the background)?

I know it's hard to get motivated when nobody looks at your bugs, but downstream bugs is not really the place where you want to be filing those. Upstream, we at least have bug triagers, and people who can help with getting more information about the problem, even if they don't correct the bug themselves.

Would be nice if you could try and reproduce the problem on a more recent version of gnome-settings-daemon.
Comment 6 amcnabb 2010-12-09 19:14:31 UTC
Isn't bugzilla.gnome.org upstream?  I posted a bug report on both of them way back in February.  In the meantime, I submitted a patch for "spanned" mode (in a separate bug report); this mode doesn't exhibit the problem, so I haven't experienced the problem in the meantime.  In December, I went back and tried to reproduce the bug (just to be helpful), but in the 5 or 10 minutes I put into it, I didn't experience it.  It had been so long that I'm not 100% confident that the bug has been fixed, but I suppose I'm not helpful for reproducing it.  So I guess the bug report should be closed, but I don't know for sure that the memory leak is really gone.  Sorry I'm not more helpful.
Comment 7 Tobias Mueller 2011-02-03 10:28:03 UTC
Closing as per last comment.