Red Hat Bugzilla – Bug 245660
Nautilus memory leaks
Last modified: 2007-11-30 17:12:08 EST
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):
100% of time
Steps to Reproduce:
1. login to GNOME
2. wait over night
notice from ps aux that up to 45% of memory (out of 2GB) is taken
memory usage should be relatively stable
see attached ps aux before and after ~6 hours
Created attachment 157818 [details]
ps aux before and after the wait (~6 hours)
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.
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"?
Actually, I am using wallpaper tray applet.... maybe it is a gconftool problem
after all.... not able to distinguish file update??
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.
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.
I am wondering if this should raise to upstream? and where to file report upstream.
I did report it on the gnome bugzilla also, but no response as of yet.
The following two reports seem to describe a similar problem. It may be a Red
Hat specific problem.
soren: Could this be the eel background patches leaking?
Yeah, this is almost certainly my fault. I'll take a look at it.
*** This bug has been marked as a duplicate of 247943 ***