Bug 247943 - nautilus leaks memory when changing backgrounds due to leak of GnomeBG's file_cache
Summary: nautilus leaks memory when changing backgrounds due to leak of GnomeBG's file...
Alias: None
Product: Fedora
Classification: Fedora
Component: gnome-desktop (Show other bugs)
(Show other bugs)
Version: 7
Hardware: All Linux
Target Milestone: ---
Assignee: Ray Strode [halfline]
QA Contact: Fedora Extras Quality Assurance
: 245660 249283 (view as bug list)
Depends On:
TreeView+ depends on / blocked
Reported: 2007-07-12 07:45 UTC by David Baron
Modified: 2007-11-30 22:12 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-08-31 19:15:47 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
stack showing where the leaked memory is allocated (5.27 KB, text/plain;charset=iso-8859-1)
2007-07-12 07:55 UTC, David Baron
no flags Details

Description David Baron 2007-07-12 07:45:30 UTC
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
background anymore.

Additional info:
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, 
"file:///home/dbaron/Pictures/2003-08-29-8-Oslo-Akershus-Panorama-1.jpg") at
#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, 
emit_setting_change=1, emit_appearance_change=1)
    at eel-background.c:573
#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)
    at nautilus-directory-background.c:294
#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.

Comment 1 David Baron 2007-07-12 07:55:14 UTC
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
same background.

Comment 2 srh 2007-08-15 21:38:32 UTC
The following two reports seem to describe a similar problem. 



Comment 3 Søren Sandmann Pedersen 2007-08-29 19:18:07 UTC
*** Bug 249283 has been marked as a duplicate of this bug. ***

Comment 4 Søren Sandmann Pedersen 2007-08-29 19:19:30 UTC
*** Bug 245660 has been marked as a duplicate of this bug. ***

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