GNOME Bugzilla – Bug 410461
Memory leak in long running gnome-terminals
Last modified: 2007-03-09 03:11:20 UTC
Please describe the problem: I left a few gnome-terminal's open overnight that were ssh'd into another machine and running a program that prints quite a bit. I came back the next morning and my memory usage was at 100%, and the system was swapping like crazy. Steps to reproduce: 1. Open a few gnome-terminals, and ssh into another machine. 2. Run a program that prints a lot (for testing just cat /dev/urandom) 3. Leave it running for about 8 hours or so Actual results: gnome-terminal eats all available memory and keeps going Expected results: gnome-terminal should not eat all my memory Does this happen every time? As it takes 8 hours to test, I'm not sure, I will try it again tonight and see what happens. Other information: this is the gnome-terminal in the fedora rawhide package: gnome-terminal-2.17.91-3.fc7
Hmm, I regularly run g-t under valgrind looking for any leak I may have introduced. Other than a few small, one-off, leaks per TerminalScreen which have already been identified and reported to their owners, to my knowledge g-t is very clean. Can you run your session under valgrind: G_SLICE=always-malloc G_DEBUG=gc-friendly valgrind \ --leak-check=full \ --leak-resolution=med \ --log-file=g-t.leaks \ gnome-terminal --disable-factory And then attach the log file (which will be called g-t.leaks.<pid>). [You will need *all* the dbgsyms in order for valgrind to correctly pinpoint the leaks.]
Created attachment 83077 [details] valgrind output attempting to demonstrate problem I didn't have the chance to run it for very long...I will run tonight all night if that will help.
The two huge leaks in that valgrind trace is in atk...
Moving to at-spi, maybe they know why this is happening?
I ran the valgrind test overnight and found in the morning that memcheck was using all my available memory, and gnome-terminal itself was using it's normal amount. For some strange reason the log file from valgrind was truncated and didn't provide any useful info. I'm not too familiar with valgrind, so I'm wondering if this is normal?
austinf, what is the version of at-spi in your machine? And the last two traces related to /usr/lib/gtk-2.0/modules/libatk-bridge.so doesn't have the function names, so it is hard to find the reason. We need better valgrind traces.
I'm now running, at-spi-1.17.2-1.fc7, but i'm not sure what i was running when I first saw this problem. I will try to get better traces with more symbols soon.
I think we have found the root cause. Li Yuan will work on a patch, soon. Thanks!
Yes, there will be leak after the user's at-spi-registryd crashed. This can be fixed by the patch of #375319. I will mark this bug as a duplicate of that bug.
*** This bug has been marked as a duplicate of 375319 ***