Description of problem: Nautilus leaks memory when changing background images.
Each time I switch images, the memory goes up, and stays up. (If I change the
sizing of an image, it spikes briefly.) According to massif, the memory at
issue is the pixbuf image storage allocated in gdk_pixbuf_new.
Version-Release number of selected component (if applicable):
How reproducible: Always
Steps to Reproduce:
1. Right click on desktop
2. Choose "Change desktop background"
3. switch to different images (particularly big ones)
Observe nautilus memory usage using top or valgrind --tool=massif.
Actual results: Memory leak.
Expected results: Background image memory freed once the image isn't the
I'm filing this in Red Hat's bugzilla rather than GNOME's because this appears
to be a bug in gnome-bg.c, which is part of the gnome-desktop package only
because of gnome-desktop-2.18.0-gnome-bg.patch . (It looks like it might be a
backport from a newer version of GNOME, given the "Since: 2.20" that appears in
it, but I'm not sure where in GNOME it comes from, and thus, where to file a
bug. And, astonishingly to me, http://svn.gnome.org/viewcvs/ has no way to
search for a file.)
What seems to be happening is the following:
* When the user changes the background image, nautilus and eel essentially
re-use an existing GnomeBG object, via the following stack:
#1 0x00cef3ea in gnome_bg_set_uri (bg=0x90bb470,
#2 0x059dbd27 in eel_background_reload_image (
background=<value optimized out>) at eel-background.c:536
#3 0x059dc958 in eel_background_set_image_uri_helper (background=0x8f9bec8,
#4 0x080fa41e in initialize_background_from_settings (file=0x8ecea08,
background=0x8f9bec8) at nautilus-directory-background.c:486
#5 0x080faaa8 in call_settings_changed (background=0x8f9bec8)
#6 0x00c54bf6 in g_timeout_dispatch (source=0x919db78, callback=0,
user_data=0x8f9bec8) at gmain.c:3422
gnome_bg_set_uri calls clear_cache to free some of the objects associated with
the previous image, but it doesn't clear file_cache. file_cache owns a
reference to the pixbuf, transferred to it when get_as_pixbuf calls
file_cache_add_pixbuf. Thus the reference in the GnomeBG's file_cache is not
freed when transitioning between background images.
I'll admit that it looks, from the code, that this *might* be intentional that
the file_cache lasts across uri changes (although I'm not sure why it would be
If it's not intended, then the correct fix would seem to be making clear_cache
free the items in file_cache.
If it is intended, however, then there are two fixes needed:
* gnome_bg_finalize needs to free the items in file_cache
* the callers in eel / nautilus need to be given some other way to free the pixbuf.
Created attachment 159037 [details]
stack showing where the leaked memory is allocated
This is the stack at which the leaked memory is allocated. (Well, actually, a
function call whose first parameter is the memory right after it's allocated,
which is a good point to break in gdb to see the address.)
I'd also note that a second reference to the same pixbuf is owned by the
pixbuf_cache member of the GnomeBG. This means that when clear_cache is
called, the g_object_unref lowers the reference count from 2 to 1; I'm
asserting that the other reference is owned by the file_cache member of the
The following two reports seem to describe a similar problem.
*** Bug 249283 has been marked as a duplicate of this bug. ***
*** Bug 245660 has been marked as a duplicate of this bug. ***