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): nautilus-2.18.1-2.fc7 How reproducible: 100% of time Steps to Reproduce: 1. login to GNOME 2. wait over night 3. 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
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. ------------ NEWNAME="wallpaper${RANDOM}.jpg" convert -geometry 1940x960! wallpaper.png $NEWNAME gconftool-2 --type string -s /desktop/gnome/background/picture_filename /home/stewart/bin/$NEWNAME ------------ 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. http://bugzilla.gnome.org/show_bug.cgi?id=464577
The following two reports seem to describe a similar problem. It may be a Red Hat specific problem. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=247943 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=249283
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 ***