[Precise] Nautilus: memory leak

[Matthieu Baerts]

Hello,

It's just to note that Nautilus has memory leaks with the latest version: with an uptime of 10 hours, Nautilus uses 420Mo.

It's maybe interesting to know that:
 * I'm using a slideshow and not one single image as background.
 * I opened Nautilus in directories where big files were being downloaded (and Nautilus regularly refreshed their preview)
 * I made a few actions (like opening directories with a lot of files, moving files, creating directories, extracting tarball, etc.)
 * I'm using a few plugins like nautilus-dropbox, nautilus-image-converter, etc.
 * I've bookmarks with special characters like 'Vidéos' and 'Téléchargements'.

I hope it will help you to fix this bug ;)

ProblemType: Bug
DistroRelease: Ubuntu 12.04
Package: nautilus 1:3.3.91-0ubuntu4
ProcVersionSignature: Ubuntu 3.2.0-18.29-generic 3.2.9
Uname: Linux 3.2.0-18-generic x86_64
ApportVersion: 1.94.1-0ubuntu2
Architecture: amd64
Date: Sun Mar 11 10:35:32 2012
GsettingsChanges:
 org.gnome.nautilus.window-state geometry '800x552+483+87'
 org.gnome.nautilus.window-state start-with-status-bar true
InstallationMedia: Ubuntu 11.10 "Oneiric Ocelot" - Alpha amd64 (20110803.1)
SourcePackage: nautilus
UpgradeStatus: No upgrade log present (probably fresh install)

[Vadim Rutkovsky (roignac)]

Thank you for taking the time to report this bug and helping to make Ubuntu better. Please try to obtain a valgrind log following the instructions at https://wiki.ubuntu.com/Valgrind and attach the file to the bug report. This will greatly help us in tracking down your problem.

[Matthieu Baerts (matttbe)]

This is what I did:
 * I installed nautilus-dbg
 * Closed nautilus: nautilus -q
 * Opened nautilus with valgrind: G_SLICE=always-malloc G_DEBUG=gc-friendly valgrind -v --tool=memcheck --leak-check=full --num-callers=40 --log-file=valgrind.log nautilus
 * Opened a directory where a video file was being downloaded (and Nautilus regularly refreshed its preview)
 * Opened a directory with a lot of other directories
 * Opened a directory with a lot of music files
        Nautilus gives us a lot of error like that:
          totem-video-thumbnailer: 'file:///path/to/a/mp3/file' isn't thumbnailable
          Reason: Media contains no supported video streams.
 * Kill Nautilus with <Ctrl> + C

Thank you!

[Vadim Rutkovsky (roignac)]

Thank you for your bug report. This bug has been reported to the developers of the software. You can track it and make comments at https://bugzilla.gnome.org/show_bug.cgi?id=671883

I see two most popular sources of leaks here:
nautilus_file_set_display_name (which is an actual nautilus trouble) and gnome_desktop_thumbnail_factory_create_failed_thumbnail

[Andre (ajx)]

It looks like Nautilus blows up to ridiculous amounts of RAM in conjunction with appmenu-gtk: Bug #788973 . This behaviour is known since Lucid: http://www.webupd8.org/2010/07/nautilus-memory-leak-fix-ubuntu-1004.html and https://answers.launchpad.net/ubuntu/+source/nautilus/+question/148866 .

I consider this as a very serious problem: Nautilus consumes currently 520MB RAM on my system (Precise, 64bit). Not every user has installed 8GB+ of RAM to satisfy the needs of Nautilus. Killing and re-opening Nautilus leads to 22MB, and 32MB when 3 windows of Nautilus are opened.

[Sebastien Bacher (seb128)]

How do you know it's an appmenu-gtk issue? Do you steps to trigger the problem?

[Andre (ajx)]

Sorry, for the confusing comment. I actually wanted to point out that 'appmenu-gtk' could/might be a possible reason.

[Jan Claeys (janc)]

I'm also seeing this bug on Precise 64-bit, but for me Nautilus grows to eat several GiB of RAM (that's "RSS", sometimes up to 8 GiB of "VIRT") before I (have to) kill it...

Just like the original reporter, some Nautilus windows/tabs might show directories with a lot (thousands) of files and/or subdirectories in them, sometimes with the subdirectories opened so that their contents are also visible (sometimes several levels deep), and there can be changes (either as a result of actions in other Nautilus windows/tabs, or by other programs) that Nautilus has to update its view for. I suppose that lots of directory entries and/or frequent updates would make the impact of memory leaks in certain code paths more visible...

I usually have about 2-5 Nautilus windows and maybe a total of 10 tabs in them open, but I don't often open/close new tabs or windows.

I also tried this with a system that had no custom nautilus extensions (so only what is installed by default, plus even some of those uninstalled), but that didn't solve the problem.

[Ari (ari-lp)]

I can confirm this bug on Ubuntu 12.04.2 LTS. It mostly appears when I am working with a large number of files. Memory usage goes from ~60 MiB at startup to >160 MiB after 10h of usage.

[Lokard (darkdadaah)]

I had the same problem on Ubuntu 12.04.2 LTS 64bits. I left my computer running during the week-end (with 4 programs running with < 100Mio usage each) and I ended up with nautilus eating 3 Gio RAM. It was the limit of my RAM and I was lucky enough to have enough responsiveness when I came back to identify and kill nautilus.

This is a critical bug since it can render a computer non-responsive if nautilus is not killed in time, however as it seems to be increasing over a long period of time, it is difficult to pinpoint what is wrong. The fact that this bug don't seem to be widespread also suggest that either the flavor of Ubuntu used is rare (12.04 64 ?), or that some special events must occur for this bug to manifest itself.

Notes :
- I don't remember having any nautilus opened
- I don't have big pictures that would need a lot of thumbnail
- I use nautilus-terminal

[Scott Long (enigmapond)]

I can still confirm this bug has yet to be fixed. This is also happening in 32bit and has nothing to do with the appmenu. I have deleted this from the start. Abnormal memory usage is leaking through nautilus and no window needs to be open for it to happen. This is critical for a system with low RAM.

[Hannes Do (hannesd-1)]

Same here with Nautilus 3.4.2.
nautilus uses 9,6 GB of RAM after running ubuntu for 14 hours.
I browsed some files, moved little text files and images (none of them are more than 2 MB). I ve opened a new Nautilus window ca. 20 times in 14 hours. If it matters: like the original reporter I also use a "slideshow" for changing dynamically the desktop wallpaper (every 10 minutes). I use variety. As far as i can say variety seems to work normal (15 MB RAM).

[Hannes Do (hannesd-1)]

Damn,
in my case it seems that variety is the problem. Everytime the desktop background is changed nautilus increases his RAM usage by ca. 300 MB which seems to be the "default" usage for one nautilus instance.

I used gnome-tweak-tool to disable the option, that nautilus manages my desktop content and now everything seems to work fine.
To mee it seems more a variety bug than a nautilus bug, but im not sure about it

[Daniel Nyström (speakman)]

Very annoying, it's currently eating 1.6GB RAM on my X86_64:
http://paste.ubuntu.com/5668805/

[Sandigliano Gianni (sandigliano-gianni)]

More Infos:
I'm also on Precise and confirm this bug it's really annoying a lot!

In my case Nautilus regularly eats memory while simply copying files.
I've started to copy a large tree of small files two days ago in the morning from an USB disk to another; the copy was the only process in a regular running state. I came back home yesterday, 36 hours later, and nautilus copy was still running using about 1/3 of my 8GB of precious RAM while copying at only 1MB/sec against usual 10-15MB/sec; CPU usage was also very high, near 100% of the used processor.
I stopped the process, rebooted and started to copy a smaller tree each time.
The memory leak was always in place for each tree I copied, increasing the memory used as well as the charge on the CPU taking care of running the process; these are collected steps:
- 1st tree (13.3GB,55k files): RAM 0.76%->1.94%(+1.18%), ~12MB/sec, ~5-6%CPU
- 2nd tree (8,5GB,30k files): RAM 1.95%->2.39%(+0.44%), ~10MB/sec, ~8-10% CPU
- 3rd tree (14,0GB,50k files): RAM 2.40%->3.52%(+1.12%), ~9MB/sec, ~11-15%CPU
- 4th tree (13,6GB,48k files): RAM 3.53%->4.55%(+1.02%), ~8MB/sec, ~14-20%CPU
- 5th tree (20,9GB,105k files): RAM 4.56%->6.69%(+2.13%), ~7MB/sec, ~17-25%CPU
- 6th tree (28,8GB,146k files): RAM 6,70%->9,86%(+2.16%), ~6MB/sec, ~20-30%CPU
The memory leak seems loosely coupled to the number of copied files, maybe to the total length of the filenames managed?
The higher CPU usage seems simply related to the waste of RAM memory.
When the copy was completed nautilus CPU usage went down to 0.17% while RAM usage remained 9.86%.

It could be interesting I'm using:
- Dropbox
- Desktop Background Image changing (Webilder)
but changing in RAM/CPU usage did not seem at all related to these processes.

[Sebastien Bacher (seb128)]

how did you measure the ram usage in that scenario of the multiple copies?

[Ari (ari-lp)]

@ sandiglioanno-gianni

> Desktop Background Image changing (Webilder)

Are those test runs you provided with this app turned off? I know you already said that there seems to be no relation between the wallpaper changer and RAM usage, but a number of users _have_ reported similar issues with Variety, which is also a background switcher. Again, just playing devil's advocate here (I am experiencing the issue without any wallpaper changer running in the background.)

[Yotis (yotisvag-g)]

Check this out.

I had the same isue after installing subclipse in eclipse.
I also had installed a few months ago RabitVCS plugin for nautilus.

The symptoms was all the same with the ones you mentioning plus that python was also mem leaking!

I removed rabitVCS cli, plugin and everything runs smooth now.

Ubuntu 12.04 amd64

[Sebastien Bacher (seb128)]

unfortunatly those reports of "it's using nG of ram after a day" are not that useful without steps to reproduce :/ The issue is not happening to everybody, or we would hear more about it/some of us would be able to reproduce. The comments suggests that some of the issues are due to plugins or projects that integrate with nautilus. There might also be a bug in nautilus trigger in some special situations (or on some special files for example), we need to figure out what those special conditions are to be able to work on it though...

[Daniel Nyström (speakman)]

I just reinstalled Ubuntu and this time the 32bit version. I will keep an eye on memory usage, and if it's still eating GB's of RAM I'll come back to this thread and request help debugging it.

[Misaki (myjunkmail311006)]

I don't know if there are multiple memory leaks, but I am reporting on this one. The Bugzilla report is not relevant to my particular version as one comment on Bugzilla says this:

>Obviously also related to wcslen so correctly closed as NOTABUG in Nautilus because it is not a bug in Nautilus.

wcslen is described as "Get wide string length. Returns the length of the C wide string wcs. This is the number of wide characters between ..."

So while the Bugzilla report as marked as RESOLVED DUPLICATE, I am reporting a new issue.

Steps to replicate:

1) Open a folder with many image files.
2) Change to list view.
3) zoom to maximum size, it's faster this way but still happens at normal size.
4) Scroll up and down.

Result, nautilus will use more memory.

The fact that it leaks memory faster at a higher zoom level indicates that it isn't related to the length of strings, but rather has to do with images somehow.

This doesn't happen in icon view. What does happen in icon view, if you zoom to maximum size, is that nautilus temporary uses more memory while it caches higher-resolution thumbnails it generates, possibly only if the existing thumbnails aren't large enough. But most or all of this memory is freed when you reload the folder or navigate away. This doesn't happen with the memory from this leak. Memory usage does go down slightly, like for me it just went from ~830 MiB or something to 780 when I went from list view to icon view, but when I did this after zooming in icon view, it went from ~230 to ~60 MiB.

When I was testing this before, it seemed like the memory didn't leak until you had scrolled far enough; just scrolling a bit, like half a page on normal zoom, didn't seem to cause a leak even when repeated. But using a high zoom makes it easy enough to replicate that details like that shouldn't matter.

In fact, simply increasing the zoom level could cause a memory leak. I just did that, without scrolling, and watched memory usage go from ~780, where I was before, up to 975 MiB. After returning to normal zoom and refreshing, memory went down to ~914. After repeating the process, over 1 GiB.

At normal size, in list view, scrolling down to the bottom of 342 images and then back up to the top causes Nautilus to use about 20 MiB more memory, each time you do it. In icon view, doing this has no noticeable effect. However, changing to list view, and then changing back to icon view, with no other actions taken, does cause memory to increase by about 6 MiB each time I do it.

New thumbnail creation is probably happening because there is high CPU use; it's possible it's not caching thumbnails in list view., or caching a limited amount or number and not freeing memory after it decides a thumbnail is no longer cached. At largest zoom, each image was adding 1.3 MiB of memory to Nautilus when I pressed down once; same thing if I pressed 'home' and 'end' repeatedly.

I'm using Nautilus 3.10.1, with Ubuntu 14.10.

[Avio (aviopene)]

I can confirm that there is a memory leak in Nautilus when looking at an image folder with an high zoom level, even as a list. I'm looking at my Dropbox Camera Uploads folder and in a couple of minutes of scrolling back and forth, selecting and deleting images, Nautilus memory usage has grown of about 1Gb up to 25% of the overall system memory (4Gb).

[jvp (jvpgr)]

ubuntu 16.04 lts, default installation and the bug persists exactly as described in posts #22 & #23

Steps to reproduce:

1/ Open a folder with more than 10.000 images
2/ See memory usage by nautilus climbing to several gigs
3/ Closing the folder does not change anything
4/ kill nautilus and memory usage returns to normal

Things get much worst if you zoom the thumbnails with every zoom step

system used amd64 with 8Gb of ram