Bug 245660 - Nautilus memory leaks
Summary: Nautilus memory leaks
Status: CLOSED DUPLICATE of bug 247943
Alias: None
Product: Fedora
Classification: Fedora
Component: nautilus   
(Show other bugs)
Version: 7
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Alexander Larsson
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2007-06-25 22:20 UTC by Edmond Hui
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-29 19:19:29 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
ps aux before and after the wait (~6 hours) (35.22 KB, text/plain)
2007-06-25 22:20 UTC, Edmond Hui
no flags Details

Description Edmond Hui 2007-06-25 22:20:39 UTC
Description of problem:

I noticed that nautilus seem to take up a lot of memory over time (i.e. over night)

Version-Release number of selected component (if applicable):


How reproducible:

100% of time

Steps to Reproduce:
1. login to GNOME
2. wait over night
Actual results:

notice from ps aux that up to 45% of memory (out of 2GB) is taken

Expected results:

memory usage should be relatively stable

Additional info:

see attached ps aux before and after ~6 hours

Comment 1 Edmond Hui 2007-06-25 22:20:39 UTC
Created attachment 157818 [details]
ps aux before and after the wait (~6 hours)

Comment 2 Dan Scholnik 2007-06-29 18:57:36 UTC
I've been having the same problem since installing FC7.  It just slowly
accumulates memory, until I kill it and it automagically restarts.  I do this a
couple of times a day.  I'm not even really using it for anything except for
desktop icons, I guess.

Comment 3 Dan Scholnik 2007-07-30 19:43:10 UTC
I figured out the source of the memory growth, not sure if it can be considered
a memory leak exactly.  I have a cron job that every 5 minutes updates the
desktop background using gconftool-2.  It seems that nautilus is caching all of
these images without limit, and it ignores any updates to the existing
background file thus requiring a new filename to be used each time.  I don't
consider this to be desired behavior, certainly.  Anyone reading this know how
to manually empty the cache besides "killall nautilus"?

Comment 4 Edmond Hui 2007-08-01 00:43:10 UTC
Actually, I am using wallpaper tray applet.... maybe it is a gconftool problem
after all.... not able to distinguish file update?? 

Comment 5 Dan Scholnik 2007-08-08 03:32:00 UTC
I tried the wp_tray and wallpapoz applets as well, both result in the same
nautilus memory growth as new images are cached.  Evidently not terribly popular
applications, or this probably would have been fixed by now.

Comment 6 srh 2007-08-12 22:07:53 UTC
I would add my voice to this problem as well. I am downloading a new image from
the internet every 30 mins, and using gconftool-2 to change the desktop
wallpaper. I have noticed that there is a memory leak, which is fixed when
nautilus is killed in System Monitor. Nautilus restarts automatically, and
desktop icons reappear etc. Leak process repeats. All of my memory can be chewed
up after about a day, so it is a serious problem.

Also, when I run gconftool-2 on the new image just downloaded, if the new image
has the same filename as the old image (new file overwrites old), gconftool-2
does not read the new image. That is, the new image displayed is from a memory
cache somewhere, not from reading the actual file on disk. To work around that,
I am creating random filenames for each new image, so gconftool-2 is forced to
look at a new file not previously in cache. Bit of a messy solution really.

convert -geometry 1940x960! wallpaper.png $NEWNAME

gconftool-2 --type string -s /desktop/gnome/background/picture_filename

I please request that this memory leak be fixed, and that gconftool-2 also be
fixed so that it reads the requested file off the disk rather than cache when
the filename is the same as a file already in cache.

Comment 7 Edmond Hui 2007-08-15 13:15:00 UTC
I am wondering if this should raise to upstream? and where to file report upstream.

Comment 8 Dan Scholnik 2007-08-15 16:50:34 UTC
I did report it on the gnome bugzilla also, but no response as of yet.

Comment 9 srh 2007-08-15 21:37:05 UTC
The following two reports seem to describe a similar problem. It may be a Red
Hat specific problem.



Comment 10 Alexander Larsson 2007-08-21 09:56:51 UTC
soren: Could this be the eel background patches leaking?

Comment 11 Søren Sandmann Pedersen 2007-08-29 18:36:14 UTC
Yeah, this is almost certainly my fault. I'll take a look at it.

Comment 12 Søren Sandmann Pedersen 2007-08-29 19:19:29 UTC

*** This bug has been marked as a duplicate of 247943 ***

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