Bug 639732

Created attachment 451300 [details]
Memory map of the problem nautilus

The attached file shows the memory map for the nautilus process leaking memory. There appears to be some very large [anon] regions in the map.

Also tried porting the gdb-heap/gdb from f14 to try to get more details on the memory allocations. See a lot of 9M allocations like the following:

All chunks of memory on heap (both used and free)
-------------------------------------------------
0: 0x00007f37e7cd5000 -> 0x00007f37e859ffff  inuse: 9220096 bytes (<MChunkPtr chunk=0x7f37e7cd5000 mem=0x7f37e7cd5010 prev_size=0 IS_MMAPPED chunksize=9220096 memsize=9220080>)
1: 0x00007f37e85a0000 -> 0x00007f37e8e6afff  inuse: 9220096 bytes (<MChunkPtr chunk=0x7f37e85a0000 mem=0x7f37e85a0010 prev_size=0 IS_MMAPPED chunksize=9220096 memsize=9220080>)
2: 0x00007f37e8e6b000 -> 0x00007f37e9735fff  inuse: 9220096 bytes (<MChunkPtr chunk=0x7f37e8e6b000 mem=0x7f37e8e6b010 prev_size=0 IS_MMAPPED chunksize=9220096 memsize=9220080>)
3: 0x00007f37e9736000 -> 0x00007f37ea000fff  inuse: 9220096 bytes (<MChunkPtr chunk=0x7f37e9736000 mem=0x7f37e9736010 prev_size=0 IS_MMAPPED chunksize=9220096 memsize=9220080>)
4: 0x00007f37ea001000 -> 0x00007f37ea8cbfff  inuse: 9220096 bytes (<MChunkPtr chunk=0x7f37ea001000 mem=0x7f37ea001010 prev_size=0 IS_MMAPPED chunksize=9220096 memsize=9220080>)
5: 0x00007f37ea8cc000 -> 0x00007f37eb196fff  inuse: 9220096 bytes (<MChunkPtr chunk=0x7f37ea8cc000 mem=0x7f37ea8cc010 prev_size=0 IS_MMAPPED chunksize=9220096 memsize=9220080>)
6: 0x00007f37eb197000 -> 0x00007f37eba61fff  inuse: 9220096 bytes (<MChunkPtr chunk=0x7f37eb197000 mem=0x7f37eb197010 prev_size=0 IS_MMAPPED chunksize=9220096 memsize=9220080>)

Created attachment 451323 [details]
script to watch for mallocs by nautilus

Wanted to see when and where the mallocs are occurring. The attached is a very simple minded script used with systemtap. Run the script with the pid of nautilus (in this case 5093):

stap   --ldd -v  /tmp/nautstack.stp -x 5093

See lots of places with 0x500000 byte allocations. That is 5MB. Why so many larges allocations. Below is a sample of the output:


nautilus(5093) process("/lib64/libc-2.12.so").function("__libc_malloc@/usr/src/debug/glibc-2.12-2-gc4ccff1/malloc/malloc.c:3614")(bytes=0x500000)
 0x32a3e799d0 : malloc+0x0/0x1f0 [libc-2.12.so]
 0x32ace05994 [libgdk_pixbuf-2.0.so.0.1800.9+0x5994/0x1e000]
nautilus(5093) process("/lib64/libc-2.12.so").function("__libc_malloc@/usr/src/debug/glibc-2.12-2-gc4ccff1/malloc/malloc.c:3614")(bytes=0x8000)
 0x32a3e799d0 : malloc+0x0/0x1f0 [libc-2.12.so]
 0x32a7e1be40 [libpng12.so.0.44.0+0x1be40/0x26000]
nautilus(5093) process("/lib64/libc-2.12.so").function("__libc_malloc@/usr/src/debug/glibc-2.12-2-gc4ccff1/malloc/malloc.c:3614")(bytes=0x500000)
 0x32a3e799d0 : malloc+0x0/0x1f0 [libc-2.12.so]
 0x32ace06435 [libgdk_pixbuf-2.0.so.0.1800.9+0x6435/0x1e000]
nautilus(5093) process("/lib64/libc-2.12.so").function("__libc_malloc@/usr/src/debug/glibc-2.12-2-gc4ccff1/malloc/malloc.c:3614")(bytes=0x500000)
 0x32a3e799d0 : malloc+0x0/0x1f0 [libc-2.12.so]
 0x32ace05994 [libgdk_pixbuf-2.0.so.0.1800.9+0x5994/0x1e000]

The machine is being switched back an forth between single head and multi head mode.

Also noticed that gnome-screensaver is taking up a lot of memory on the system:

top - 20:54:38 up 3 days, 10:05,  5 users,  load average: 1.03, 1.14, 0.89
Tasks: 257 total,   2 running, 255 sleeping,   0 stopped,   0 zombie
Cpu(s):  5.7%us,  4.3%sy,  0.0%ni, 72.4%id, 16.7%wa,  0.1%hi,  0.7%si,  0.0%st
Mem:   3716868k total,  3592616k used,   124252k free,    82908k buffers
Swap:  5947384k total,   595084k used,  5352300k free,  1980216k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND            
 4031 wcohen    20   0 1129m 418m  19m S 10.6 11.5  11:02.18 firefox            
 3345 wcohen    20   0  677m 110m 3524 S  0.0  3.0   0:27.66 gnome-screensav    
 5093 wcohen    20   0  596m  93m  13m S  0.0  2.6   0:05.45 nautilus

Thanks for debugging this, since Nautilus also manages desktop background, it might be leaking some objects when extending/shrinking the desktop (xrandr events). Or, but unlikely, there's a leak when decoding an image file, either desktop background or some thumbnail elsewhere. 

Try living a moment without desktop background, set it to solid color. This will help us to identify the leak. Still, we might be allocating same sized pixmap with solid color.

I will go with the solid background to see if that improves things.

The background was originally the default background that cycles through the various background ?????x????_dawn.png, ????x????_day.png, etc. Not sure what size was being used. The laptop screen doesn't fix the list of resolutions.

The lcd screen of the laptop is 1600x900.  At home I plug it into a viewsonic 1280x1024 monitor into the vga output and and at work I have a princeton monitor that is also 1280x1024. Maybe having the different monitors on the output is triggering the memory leak

If you have some method of running valgrind on nautilus, I am willing to try that out and see where those memory allocations are coming from.

(In reply to comment #6)
> If you have some method of running valgrind on nautilus, I am willing to try
> that out and see where those memory allocations are coming from.
This is not easy. Try running `nautilus -q` but there's a high risk that session respawns nautilus back automatically. In that case, something like 
> for i in `seq 1 20`; do pkill nautilus; done
might do the trick. If that doesn't help either, try removing filemanager from /desktop/gnome/session/required_components_list gconf key and logout.

Once nautilus is dead, you can try running nautilus under valgrind. Quitting it by `nautilus -q` would show final valgrind report.

I'm having a similar problem with the i386 version of RHEL 6.  I noticed that after changing the background from the default dynamic version of it to a static background the leak has stopped.

I running the 64bit version and is also affected by this. Atleast when running the dynamic background. Nautilus quickly grows to around 700MB of RAM after a few hours. Any news on this bug ?

Same here. Will verify if user is indeed using any fancy screensaver/wallpaper setup.

I also have the problem on a X301
I do not have any screensavers at all running. There is the standard
gnome-screensaver lock
I also switch frequently between single head and multihead
I don't have anything fancy for a background just a nasa picture of some
galaxy. However, when the screens resize it does seem to resize or do something
with the background.

It is very hard (as in I haven't been able to do it yet) to attach valgrind to
nautilus because gnome-session. I tried stopping gnome-session and then
starting nautilus but that didn't work.

killing nautilus frees up the memory. gnome-session restarts it quickly.

I also have this bug on RHEL 6.1 Workstation. It is starting to sound like it's the rotating background image. I used a tool that would generate one for me from some high resolution pictures of my own. It seems to grow about 2GB a day for me.

Killing nautilus also works, and gnome-session also restarts it quickly. So I've been doing that for about a week now.

With a non-rotating background, my memory usage hasn't changed much at all for Nautilus. It's enough for me to blame the rotating-background feature having a memory leak.

I also confirm, that if I change my background to "No Desktop Background", my workstation becomes to usable condition. 

Well, if any of backgrounds, except "no background", are enabled, my desktop is out of memory (4Gb) in a two-three days, even if I don't use it at all!

I had the same issue on RHEL 6.1 Workstation, MSI G-Series laptop with two external LCDs connected. It seems it has been solved by turning off the default rotating background.

It's been more than a year. Still "Status: NEW".
You go, RedHat!

30197 jroys3    20   0 8554m 5.6g 5496 S  0.0 72.2  10:33.89 nautilus
and
 2874 jroys3    20   0 5760m 4.6g 8232 S  0.0 58.5   6:53.58 nautilus

# cat /etc/redhat-release 
Red Hat Enterprise Linux Server release 6.1 (Santiago)

Looks like this is fixed upstream: http://git.gnome.org/browse/gnome-desktop/commit/libgnome-desktop/gnome-bg.c?id=af477956ddd06e3821bbcc3e9337a637fe91584a

Tested on local dual-monitor setup with success with the above patch.

Steps to reproduce:
 1. Setup a dualmonitor machine using Gnome desktop
 2. Change the desktop background to rotating one, e.g. 'Cosmos'
 3. To speed up backgrounds changing, edit the '/usr/share/backgrounds/cosmos/background-1.xml' file and change "1795" with a lower value, say "5"
 4. Notice the memory consumption coming up rapidly

*** Bug 766889 has been marked as a duplicate of this bug. ***

After
  884 jroys3    20   0 5416m 4.7g  14m S  0.0 61.6   6:19.76 nautilus
and
  918 jroys3    20   0 2345m 1.6g  20m S  0.0 20.9   2:09.73 nautilus
and
25212 jroys3    20   0 1649m 1.0g  20m S  0.0 12.9   1:18.45 nautilus
and
 7633 jroys3    20   0 5739m 4.4g  17m S  0.0 57.3   6:54.64 nautilus
back-to-back (it would take a under a week usually), I patched gnome-desktop locally and the leak has stopped.

FYI, I don't have rotating backgrounds or anything fancy.  The only thing unusual is two monitors of different screensize/resolutions.

Actually, I take that back.  They do rotate- I just am never around when they do.  </whine>

*** Bug 680956 has been marked as a duplicate of this bug. ***

    Technical note added. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    New Contents:
Cause: An object not being destroyed

Consequence: Constantly growing resident memory led to memory exhaustion, crashes and system slowdowns.

Fix: A memory leak has been fixed

Result: No more exhaustive memory consumption

    Technical note updated. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    Diffed Contents:
@@ -1,7 +1 @@
-Cause: An object not being destroyed
+Previously, due to an object not being destroyed, the Nautilus file manager could consume an excessive amount of memory. Consequently, constantly growing resident memory would slow down the system. The source code has been modified to prevent memory leaks from occurring and Nautilus now consumes a reasonable amount of memory.-
-Consequence: Constantly growing resident memory led to memory exhaustion, crashes and system slowdowns.
-
-Fix: A memory leak has been fixed
-
-Result: No more exhaustive memory consumption

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHBA-2012-0405.html