nautilus memory leak

Bug #890441 reported by MFeif
34
This bug affects 7 people
Affects Status Importance Assigned to Milestone
nautilus (Ubuntu)
Fix Released
Medium
Unassigned

Bug Description

There are other bug reports with this description, but they are either 3-4 years old, or closed, or invalid, or expired.

I'm not doing anything exotic, but after about an hour or two of using my system (not even copying or moving files, or thumbnailing, or...) memory usage in nautilus goes up to 1.4G or so. When I kill this task, re-launch nautilus, it sits happily on just a few hundred meg... and then begins to grow again.

It also takes a LONG time to start up, and the system is very unresponsive meanwhile... like 20 seconds. This may be a useful clue?

I tried to do a valgrind report, but it makes nautilus so slow as to be unusable -- like 2 minutes to open a folder on the desktop... so I couldn't exactly "use it normally" to get a good log. Nonetheless, here's a log I did capture.

I trust that the data captured by ubuntu-bug will have my library versions, cpu type, RAM info, etc. Please let me know what else I can provide. Thanks!

ProblemType: Bug
DistroRelease: Ubuntu 11.10
Package: nautilus 1:3.2.1-0ubuntu3.1
ProcVersionSignature: Ubuntu 3.0.0-13.22-generic 3.0.6
Uname: Linux 3.0.0-13-generic x86_64
NonfreeKernelModules: nvidia
ApportVersion: 1.23-0ubuntu4
Architecture: amd64
Date: Mon Nov 14 15:51:46 2011
InstallationMedia: Ubuntu 11.10 "Oneiric Ocelot" - Alpha amd64 (20110802.1)
ProcEnviron:
 PATH=(custom, no user)
 LANG=en_US.UTF-8
 SHELL=/bin/bash
SourcePackage: nautilus
UpgradeStatus: Upgraded to oneiric on 2011-08-17 (88 days ago)

Revision history for this message
MFeif (matt-feifarek) wrote :
Changed in nautilus (Ubuntu):
importance: Undecided → Medium
Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in nautilus (Ubuntu):
status: New → Confirmed
Revision history for this message
Christoph Linecker (clinecker) wrote :

Regarding memory usage and overall responsiveness - I'm experiencing the exact same problems.

Revision history for this message
Ian Butterss (ian-butterss) wrote :

I am having this too, whenever the Nautilus file manager is open. Eventually it slows to a grind. Even when not navigating folders and files, memory requirement goes up steadily. Even when Nautilus was set just to handle my desktop.

Ubuntu 11.10 64 bit

Revision history for this message
Gianfranco Costamagna (costamagnagianfranco) wrote :

This bug should be fowarded upstream, and maybe running it in valgrind could help in fixing the problem

Revision history for this message
Sebastien Bacher (seb128) wrote :

Thank you for your bug report, does it increase usage if you don't use it or only when you actively work with nautilus?

you have those non standard components installed:
kupfer 0+v206-1
nautilus-dropbox 0.7.0
python-nautilus 1.0-0ubuntu2

does it happen without them installed?

Changed in nautilus (Ubuntu):
status: Confirmed → Incomplete
Revision history for this message
MFeif (matt-feifarek) wrote :

Sebastien, it's hard to tell; I have nautilus painting the desktop, so it's always "in use". I don't have a solid opinion about this, but yes, it *seems* to happen ALWAYS, but worse when there is a lot of nautilus use.

I am using kupfer, yes... but there is no nautilus plugin, so if Kupfer is using public services of nautilus, it's still a nautilus bug, right? I will try to run without kupfer to see what happens.

I also use Dropbox, but my system reports version 0.7.1

I do NOT have python-nautilus installed.

Revision history for this message
Sebastien Bacher (seb128) wrote :

what I call "in use" is like interacting with it rather than letting it "sit there"

the ubuntu-bug collecting job added that list to the bug:
https://launchpadlibrarian.net/85141332/usr_lib_nautilus.txt

which is the packages you have installed which add a .so to the nautilus directory

so that seems to not be coherent with your comments...

to reply to your other question, no, leaks are not especially a nautilus bug, they can be due to third party softwares which install some .so loaded by nautilus, leaks in those would show in the nautilus process since that's where they are loaded, the 3 packages listed in comment #6 do install a such .so and could be causing the issue (the other ones in the list of the file I listed as well but those are installed by default and would affect all users where your issue is not something most users notice)

Revision history for this message
MFeif (matt-feifarek) wrote :

Sorry, you're right about python-nautilus!

I did "aptitude show python-nautilus" and saw the "Automatically installed: no" and read it as "installed: no". My mistake. No applications seem to be using it, so I purged it.

I understand your explanation, thanks for that. But I don't know how to proceed... Nautilus is what is eating RAM; if it's because it loads something else, well, fine... Should I try and get a memory map dump or something while it is large?

Others following this bug, are you using Kupfer / Dropbox / Python-Nautilus?

Revision history for this message
MFeif (matt-feifarek) wrote :

I made another comment; it doesn't seem to be here!

I have looked in the "memory map" feature of Gnome-System-Monitor, and the big chunk is "[heap]" currently sitting on 367MiB.

The various .so files do appear below, but all are taking up almost no memory.

Does this help?

Revision history for this message
MFeif (matt-feifarek) wrote :

Ok, I quit Kupfer, I quit Dropbox, I killed Nautilus, then re-opened it; of course the desktop re-painted.

I'm using Gnome-System-Monitor to watch. I'm watching the "Processes" tab.

Nautilus started out eating ~ 26M of RAM at first. I have opened no file explorers, done nothing other than have the desktop open.

After about 5 minutes, it's up to 55.3 MiB. If you watch, it adds about 0.1 MiB per second... it just keeps creeping up.

Interestingly, if I open an "explorer" window, it jumps up a bit (of course) and when the window is closed it doesn't release that memory... but the creeping-up seems to stop.

So this is all very anecdotal. What else can I provide?

Revision history for this message
Sebastien Bacher (seb128) wrote :

Quiting those is not enough, the isuee could be in their .so, what you could do is either uninstall the packages or simply rename the /usr/lib/nautilus directory on disk and restart nautilus, if the issue doesn't happen then you will know it comes from one of those .so installed in the nautilus directory, then you can iterate until finding which one

Revision history for this message
Sebastien Bacher (seb128) wrote :

ok, so trying on an oneiric system there nautilus starts around 16mb and is still using that after 15 minutes, so it's clearly not all systems

something else you can try is to change nautilus to not display the background:
- run gsettings set org.gnome.desktop.background show-desktop-icons false
- then run nautilus --quit
- then run nautilus in valgrind, that will open a browser window, let it open for 5 minutes then close it, that should quit nautilus since it's not displaying the background and no view is kept open
- then attach the valgrind log to the bug

getting a log this way might be better since nautilus will be closed "properly" there which will let valgrind get a better summary or what memory was freed as it should (if you stop it with --quit or ctrl-C you might prevent some callbacks to run which will change the summary)

Revision history for this message
MFeif (matt-feifarek) wrote :

Thanks Sebastien.

I'll try moving the extension dir out of the way and running nautilus as you suggest.

Did you see my comment about looking at the memory map? Very little memory is claimed by those .so files, for whatever it's worth.

Revision history for this message
Sebastien Bacher (seb128) wrote :

the .so are mmaped in the process so they will show up as nautilus code so that doesn't mean they don't create the issue

Revision history for this message
MFeif (matt-feifarek) wrote :

Ok, I did some tests...

1. When nautilus does NOT draw the desktop, memory use stays put at around 20M and does not grow. This is without moving the extension directory, so Dropbox and Kupfer could still be active.

2. If I move aside that extensions directory and restart nautilus, if it is set to draw the desktop, the growing memory behavior continues... again, even if the extensions are not in place.

I attached a valgrind dump that represents #2 state: with extensions removed but desktop drawn. Given that without desktop drawn, the memory use is normal, I didn't see a point in attaching another log. I hope that's ok.

Revision history for this message
Sebastien Bacher (seb128) wrote :

Thank you for the work on the issue

the log doesn't have obvious issues, did you let it running for a while? how much the resources usage changed?

Do you have any special file on your desktop that requires thumbnailing (image, svg, video, ...)? Do you download things there (i.e do you have files changing regularly which could trigger frequent refreshes for the view?)

Changed in nautilus (Ubuntu):
status: Incomplete → New
Revision history for this message
MFeif (matt-feifarek) wrote :

Sigh.

I let it run for about 15 minutes. I tried to "use" it, but like I said, it takes about 1m just to open a window. So I didn't use it "much".

It's not possible to monitor the resource usage of nautilus when it's running inside of valgrind, because it's not in the System Monitor anymore... a 500MB task that wraps it up is instead. What's happening inside of this appears to be opaque to the tools I have.

I have about 15 items on the "desktop"... one perhaps clue is that I have the "desktop" set to ~/ via the gconf settings. This means that there are very many ".dotfiles" which are hidden to nautilus as it paints the desktop.

There is one .png on the desk, but it hasn't updated in weeks. I'm not downloading anything there (I have Downloads, ala Ubuntu standard).

To pursue this line of reasoning, I've turned off everything on the "Preview" tab of the nautilus preferences... removed most of the files from the "~" to clean the "desktop" and restarted nautilus. I'll watch it for a while and report back.

One probably irrelevant thing: I see TONS of these in .xsession-errors: "(nautilus:18652): Gtk-CRITICAL **: gtk_container_foreach: assertion `GTK_IS_CONTAINER (container)' failed"

Revision history for this message
MFeif (matt-feifarek) wrote :

Ok, after about 30m, I see the same familiar behavior...

After starting at around 25M, nautilus is not sitting on 134.9MiB, rising 200-300KiB per second.

Now what?

Revision history for this message
Sebastien Bacher (seb128) wrote :

does it happen if you set the desktop to be the desktop dir and not your user dir?

Revision history for this message
MFeif (matt-feifarek) wrote :

No, it does not happen; I found two places where this setting was set:

1. In gconf : apps / nautilus / preferences / desktop_is_home_dir
(this setting appears to have no effect, but was a carry-over from an old version of Ubuntu. -- is nautilus gtk3 or gtk2 at this point?)

2. in .config/user-dirs.dirs -- this setting does affect nautilus.

I ran with "normal" configuration (with a desktop folder) for a while, and nautilus behaved. I switched it back and there it goes...

Revision history for this message
Sebastien Bacher (seb128) wrote :

Oneiric is using gsettings for nautilus not gconf, so the equivalent setting would be "gsettings get org.gnome.nautilus.preferences desktop-is-home-dir" (or set true,false on the same key)

what did you change in your .config?

Revision history for this message
MFeif (matt-feifarek) wrote :

"gsettings get org.gnome.nautilus.preferences desktop-is-home-dir" returns "false"

I changed:

XDG_DESKTOP_DIR="$HOME/"

to

XDG_DESKTOP_DIR="$HOME/Desktop"

which stopped the problem. Changing it back started it again.

Where are gsettings actually stored, and is dconf the same thing?

Revision history for this message
Sebastien Bacher (seb128) wrote :

ok, so you changed it using the xdg definition and not the gsettings key, that's interesting, not sure it gives enough infos to show where the issue is but it could explain why you see it and most users don't

Revision history for this message
MFeif (matt-feifarek) wrote :

FYI, I get the same behavior if I set the gstettings key and revert the xdg settings to "normal"...

Revision history for this message
MFeif (matt-feifarek) wrote :

So, Sebastien, what's the next step here.

I think I've provided enough context to reproduce and prove that it is not some other setting on my system?

I see that the bug is still "New"...

Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in nautilus (Ubuntu):
status: New → Confirmed
Revision history for this message
dino99 (9d9) wrote :

What i get on Precise i386:

- on cold boot, nautilus use around 10 Mib
- then xsession-errors is recording continously gtk-critical errors, mainly due to both Unity, so i've purged them to slow down this madness. Purging/reinstalling several times or reconfiguring dont help on that side. About 10 Mib errors are recorded per hour and ram used by nautilus is growing the same way , increasing by 10 Mib /hour.
- nautilus seems to fill ram with all the events/errors of the system, wonder if zeitgeist is the cause, but cant be removed easily from the system.
- even if the nautilus gui is closed, the amount of ram used is not reduced.

Hope a fix, as nautilus might be only a browser.

Revision history for this message
dino99 (9d9) wrote :

More comment about post #28 above:
- unity 2d & 3d was completly purged, and their dependencies & related packages too.

 - but while booting i always got stuck to "checking battery state"
- looking at lightdm, it need EITHER lightdm-gtk-greeter (was installed) OR unity-geeter. Thats wrong, unity-greeter needs to be installed to get lightdm login screen, then X start, otherwise i have to log via tty.

As a result: nautilus dont eat ram without unity-greeter, but with it installed nautilus is continously eating ram (a bit less than with the whole unity, but)

Revision history for this message
Sebastien Bacher (seb128) wrote :

Thanks for your work matt, I'm out of ideas on how to get useful informations on that issue though, it doesn't happen on any of the boxes I use and doesn't seem to impact most users so it's not easy to debug

dino99: unity-greeter is a gtk "software" running on the login screen with another user, there is no reason it should change things in the user session. What warnings do you get in .xsession-errors? .xsession-errors increase by ~10kb an hour here

Revision history for this message
Sebastien Bacher (seb128) wrote :

> - looking at lightdm, it need EITHER lightdm-gtk-greeter (was installed) OR unity-geeter. Thats wrong, unity-greeter needs to be installed to get lightdm login screen, then X start, otherwise i have to log via tty.

you need to edit your lightdm.conf to tell it to load the gtk greeter if that's the one you want to use

Revision history for this message
Julien Faucher (julien-faucher) wrote :

For what it's worth, I had the same problem in Nautilus 3.2.1, using my home folder as the desktop with a modified user-dirs.dirs . The issue is present on both my computers (one with Oneiric, the other running Mint 12, but it's the same package AFAIK) and it happens with the user-dirs.dirs modification as well as with the dconf setting. For both computers, switching back to the default ~/Desktop directory makes the leak go away.

For now I was able to fix the problem by downgrading to Nautilus 3.2.0 (package 1:3.2.0-0ubuntu5).

If I can provide any other info to help you resolve this bug, please tell me.

Revision history for this message
dino99 (9d9) wrote :

@Sebastien

here is xsession-errors requested into #30 above to let you know about what kind of errors are logged, note that its the result obtained after a cold boot a few minutes back. Nautilus is growing the same way, eating memory.

Revision history for this message
Sebastien Bacher (seb128) wrote :

do you get those warning from nautilus? could you get a stacktrace for one of those? doing that should work:
nautilus --quit
gdb nautilus
(gdb) b g_log
(gdb) run
...
type "c" if it stops on something else or "bt" when you get one of the warnings

Revision history for this message
dino99 (9d9) wrote :
Download full text (7.3 KiB)

Thanks for the guideline, here is what i get:

oem@oem-desktop:~$ nautilus --quit
oem@oem-desktop:~$ gdb nautilus
GNU gdb (Ubuntu/Linaro 7.3.1-2011.12-0ubuntu2) 7.3-2011.12
Copyright (C) 2011 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "i686-linux-gnu".
For bug reporting instructions, please see:
<http://bugs.launchpad.net/gdb-linaro/>...
Reading symbols from /usr/bin/nautilus...Reading symbols from /usr/lib/debug/usr/bin/nautilus...done.
done.
(gdb) b g_log
Breakpoint 1 at 0x8061b90
(gdb) run
Starting program: /usr/bin/nautilus
[Thread debugging using libthread_db enabled]
[New Thread 0xb6757b70 (LWP 24648)]
[New Thread 0xb5dffb70 (LWP 24649)]
[New Thread 0xb55feb70 (LWP 24650)]
Initializing nautilus-gdu extension
[New Thread 0xaf44eb70 (LWP 24651)]

Breakpoint 1, 0xb7386f30 in g_log () from /lib/i386-linux-gnu/libglib-2.0.so.0
(gdb) c
Continuing.

Gtk-CRITICAL **: gtk_container_foreach: assertion `GTK_IS_CONTAINER (container)' failed

Breakpoint 1, 0xb7386f30 in g_log () from /lib/i386-linux-gnu/libglib-2.0.so.0
(gdb) bt
#0 0xb7386f30 in g_log () from /lib/i386-linux-gnu/libglib-2.0.so.0
#1 0xb7386fad in g_return_if_fail_warning () from /lib/i386-linux-gnu/libglib-2.0.so.0
#2 0xb792e18b in gtk_container_foreach () from /usr/lib/i386-linux-gnu/libgtk-3.so.0
#3 0xb792e785 in gtk_container_get_children () from /usr/lib/i386-linux-gnu/libgtk-3.so.0
#4 0xb7b1a937 in ?? () from /usr/lib/i386-linux-gnu/libgtk-3.so.0
#5 0xb7b1a9ad in ?? () from /usr/lib/i386-linux-gnu/libgtk-3.so.0
#6 0xb7b1a9ad in ?? () from /usr/lib/i386-linux-gnu/libgtk-3.so.0
#7 0xb7b1eff8 in gtk_ui_manager_ensure_update () from /usr/lib/i386-linux-gnu/libgtk-3.so.0
#8 0xb7b1f082 in ?? () from /usr/lib/i386-linux-gnu/libgtk-3.so.0
#9 0xb7b1e296 in gtk_ui_manager_get_widget () from /usr/lib/i386-linux-gnu/libgtk-3.so.0
#10 0x080c44bc in nautilus_menus_append_bookmark_to_menu (window=0x82dc090, bookmark=0x8499ef0,
    parent_path=0x816b850 "/MenuBar/Other Menus/Bookmarks/Bookmarks Placeholder",
    parent_id=0x81685cf "dynamic", index_in_parent=0, action_group=0x8489490, merge_id=16,
    refresh_callback=0x80c4510 <refresh_bookmarks_menu>,
    failed_callback=0x80c3c00 <show_bogus_bookmark_window>) at nautilus-window-bookmarks.c:343
#11 0x080c47e2 in update_bookmarks (window=0x82dc090) at nautilus-window-bookmarks.c:392
#12 refresh_bookmarks_menu (window=0x82dc090) at nautilus-window-bookmarks.c:410
#13 0xb743e35c in g_cclosure_marshal_VOID__VOID () from /usr/lib/i386-linux-gnu/libgobject-2.0.so.0
#14 0xb743cdac in g_closure_invoke () from /usr/lib/i386-linux-gnu/libgobject-2.0.so.0
#15 0xb744e0c5 in ?? () from /usr/lib/i386-linux-gnu/libgobject-2.0.so.0
#16 0xb7455942 in g_signal_emit_valist () from /usr/lib/i386-linux-gnu/libgobject-2.0.so.0
#17 0xb7455ad3 in g_signal_emit () from /usr/lib/i386-linux-gnu/libgobject-2.0.so.0
#18 0x0806a204 in load_file_finish (res=0x84a5520, source=0x8318850, bookmarks...

Read more...

Revision history for this message
dino99 (9d9) wrote :

#35 head up

found a very close issue reported into Bug #886419 regarding libdbusmenu-gtk3-4. its on Precise i386 logged as gnome-classic (compiz/unity completly purged).

cases:
- if start it again into a terminal: i get a bunch of gtk-critical errors, when "nautilus is used.
- but "gksu nautilus" dont produce warnings at all

oem@oem-desktop:~$ gksu nautilus
Initializing nautilus-gdu extension

Revision history for this message
Sebastien Bacher (seb128) wrote :

dino99:
- do you get the same warning under unity? (just to know if the session makes a difference)
- the bug you point is a segfault and the stacktrace contains libdbusmenu, yours doesn't
- does moving .gtk-bookmarks away workaround the issue? it seems to be due to your bookmarks somewhat
- could you get a stacktrace with the gtk3 dbg package installed?

Revision history for this message
dino99 (9d9) wrote :

Unity is not installed nor compiz (totaly purged)

Looking at .gtk-bookmarks show an issue with dir/subdir names if thet contain "é": translated with % + uppercase letters.
Had Vidéos & Téléchargement dirs , both was malformed into .gtk-bookmarks. Now i've replaced "é" by "e" to avoid this issue. But need to fix it anyway; i'm using fr_FR-UTF8 as page code.

This temporary workaround dont remove the gtk-crital errors into .xsession-errors, get the same but far less numerous.
Nautilus service at early gnome-classic session (without effect) is using ~10 Mib; if the filebrowser is opened then the ram used grows to 14; opening firefox browser then nautilus use around 20 Mib.

 I've taken time to observe how that going on: ram crunching seems have stopped (good news) and the early errors logged to xsession-errors dont have new error added. That said, since i've renamed the faulty dirs names, i get this new error:

** CRITICAL **: enchant_dict_check: assertion `g_utf8_validate(word, len, NULL)' failed

About your request above "gtk3 dbg package", i've looked at synaptic archive list about "gtk3" and dont find -dbg package except for canberra; which one(s) do you need ?

AS a result this nautilus issue seems to be a "language" issue as special letters as "é" are not understood by the system directories. (this system is fully non-stop updated)

Revision history for this message
dino99 (9d9) wrote :

Latest packages installed: language-pack-fr, language-pack-en, language-pack-gnome-fr & en 1.12.04+20111229

After having renamed the faulty names dirs and set a clean .gtk-bookmarks, finally made a cold reboot. Get the usual errors logged into xsession-errors attached. No more errors added then.

Revision history for this message
Sebastien Bacher (seb128) wrote :

Those are useful informations, do you remember how you added this bookmarks? The accents should be supported but maybe something did wrong escaping or encoding when it wrote there.

In any case your issue is a valid bug but different from the leak (or at least it seems so), could you open a new bug about it using "ubuntu-bug nautilus" and adding those informations? I will look at getting that issue resolutions

The gtk3 debug package is libgtk-3-0-dbg

Revision history for this message
Sebastien Bacher (seb128) wrote :

Ok, your new log has other errors, you might want to open another bug for the enchant one and get a stacktrace the same way

Revision history for this message
Sebastien Bacher (seb128) wrote :

> clean .gtk-bookmarks, finally made a cold reboot. Get the usual errors logged into xsession-errors attached. No more errors added then.

did you check that .gtk-bookmarks didn't get recreated on boot? it's automatically created on first login usually if not existant (that's how you get bookmarks set on new accounts)

Revision history for this message
dino99 (9d9) wrote :

Stacktrace about nautilus again?

Additional comments since previous post:
- running a new app ( with wine) add the same errors at opening time, but no more then.
- have looked at an other system with Oneiric i386: it has the same errors logged and again into .gtk-boomarks "Vidéos" is translated "Vid%C3%A9os". So Oneiric is concerned too for the same reasons. Renaning to "Video" and removing .gtk-bookmarks solve the issue. This system was dist-upgraded from Natty (xsession-error was quite empty with Natty)

Revision history for this message
dino99 (9d9) wrote :

here is a new gdb nautilus, with libgtk-3-0-dbg installed

Revision history for this message
dino99 (9d9) wrote :

Still confirm, after many hours of observation without logout/reboot, that nautilus use normal low memory. So on my system, the "leak" was due to bad encoded name dirs and/or config files related to "accented letters" translated to garbage and producing a bunch of gtk errors.

Revision history for this message
Sebastien Bacher (seb128) wrote :

let's continue the discussion about those warnings in bug #912379

@matt: do you use Unity or another session?

Revision history for this message
MFeif (matt-feifarek) wrote :

I'm in Gnome Shell.

Revision history for this message
Sebastien Bacher (seb128) wrote :

Could you try if running DESKTOP_SESSION=ubuntu nautilus makes things better for you?

Revision history for this message
MFeif (matt-feifarek) wrote : Re: [Bug 890441] Re: nautilus memory leak

Sure, that's an environment variable, I expect ... how do I set this so
that it takes precedence?

On Mon, Jan 9, 2012 at 3:24 AM, Sebastien Bacher <email address hidden> wrote:

> Could you try if running DESKTOP_SESSION=ubuntu nautilus makes things
> better for you?
>
>

Revision history for this message
Sebastien Bacher (seb128) wrote :

running nautilus --quit followed by "DESKTOP_SESSION=ubuntu nautilus" on a command line should work

Revision history for this message
dino99 (9d9) wrote :

@Sebastien

Nicely done:
nautilus (1:3.2.1-2ubuntu7) precise; urgency=low

  * debian/patches/05_desktop_menu_export.patch:
    - drop the hack to avoid the nautilus menubar displayed on the desktop on
      non unity session, it's buggy, spam the session log and the issue
      has been fixed properly in gtk with a recent update (lp: #912379)

now , logged as gnome-classic, xsession-error is quite clean, no more error flooding as before; thats really works, thanks. And of course the memory leak is solved too on my end.

Revision history for this message
MFeif (matt-feifarek) wrote :

That did it; Nautilus behaves, after a whole day, is only eating 40M.

Well done!

dino99 (9d9)
Changed in nautilus (Ubuntu):
status: Confirmed → Fix Released
Revision history for this message
Jameson Williams (jamesonwilliams) wrote :

It would be excellent to upload this fix release package to oneiric-updates or oneiric-backports as appropriate.

Revision history for this message
Sebastien Bacher (seb128) wrote :

the fix is difficult to backport since it relies on the new unstable glib and gtk series

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.