Ever since I updated to post-FC6 rawhide on my x86-64 system, gnome-terminal has been unreliable. It occasionally crashes, often at strange times. I put it into Bugzilla (https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=217378) but have not heard any more - how dare people not fix my bug (for free) within 24 hours?!? :)
I am curious, though, as to whether I'm really the only one who sees this. The problem appears to be related to a memory leak. A quick ps on my system shows:
corbet 14974 0.0 5.4 333732 55532 ? Ssl Nov27 0:13 gnome-terminal
A 300MB address space (50MB resident) is a bit on the hefty side, even considering that we're talking about a GNOME application here. Doing the same thing an hour later shows this:
corbet 14974 0.0 5.0 341236 52032 ? Ssl Nov27 0:14 gnome-terminal
Whereas when I put in the BZ entry I had this:
corbet 14974 0.0 2.3 295520 24288 ? Rsl 07:54 0:02 gnome-terminal
In other words, the thing is growing at a fast and steady rate.
Personally, I think that a terminal emulator should know its place, and gnome-terminal has failed to keep within its bounds. Is this something special it's doing for me, or is it a wider problem?
Thanks,
jon
On Tue, Nov 28, 2006 at 12:41:56PM -0700, Jonathan Corbet wrote:
Personally, I think that a terminal emulator should know its place, and gnome-terminal has failed to keep within its bounds. Is this something special it's doing for me, or is it a wider problem?
Just checking, but: how big of a scrollback buffer do you have configured?
Matthew Miller mattdm@mattdm.org wrote:
Just checking, but: how big of a scrollback buffer do you have configured?
500 lines.
jon
On Tue, Nov 28, 2006 at 12:41:56PM -0700, Jonathan Corbet wrote:
Ever since I updated to post-FC6 rawhide on my x86-64 system, gnome-terminal has been unreliable. It occasionally crashes, often at strange times. I put it into Bugzilla (https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=217378) but have not heard any more - how dare people not fix my bug (for free) within 24 hours?!? :)
I am curious, though, as to whether I'm really the only one who sees this. The problem appears to be related to a memory leak. A quick ps on my system shows:
corbet 14974 0.0 5.4 333732 55532 ? Ssl Nov27 0:13 gnome-terminal
A 300MB address space (50MB resident) is a bit on the hefty side, even considering that we're talking about a GNOME application here. Doing the same thing an hour later shows this:
corbet 14974 0.0 5.0 341236 52032 ? Ssl Nov27 0:14 gnome-terminal
Whereas when I put in the BZ entry I had this:
corbet 14974 0.0 2.3 295520 24288 ? Rsl 07:54 0:02 gnome-terminal
In other words, the thing is growing at a fast and steady rate.
Personally, I think that a terminal emulator should know its place, and gnome-terminal has failed to keep within its bounds. Is this something special it's doing for me, or is it a wider problem?
The memory usage reported by 'ps' or 'top' is essentially /useless/ as a source of information about how much memory is actually used by a program.
On x86_64 in particular, libraries are mapped into memory on very coarse granularity, but the actual usage is nowhere near the map size. A freshly launched gnome-terminal on i386 has a mapped size of 49 MB, while x86_64 it is 430 MB. The actual resident size though is ~20 MB on i386, or 30 MB on x86_64, which is pretty reasonable - particularly when you then look at how much of this is shared vs private mappings.
The size of private mappings in gnome-terminal appears to be principally related to number of tabs / windows open & the scrollback size.
Anyway if you want to examine actual memory maps / usage to get some real memory figures look at /proc/[PID]/smaps rather tha top/ps. That file's rather unpleasent to read, so its useful to post-process it
http://people.redhat.com/berrange/mem-monitor/
Regards, Dan.
On Tue, Nov 28, 2006 at 07:57:24PM +0000, Daniel P. Berrange wrote:
Anyway if you want to examine actual memory maps / usage to get some real memory figures look at /proc/[PID]/smaps rather tha top/ps. That file's rather unpleasent to read, so its useful to post-process it http://people.redhat.com/berrange/mem-monitor/
Hey, that'd be handy in Extras. :)
Daniel P. Berrange wrote:
On Tue, Nov 28, 2006 at 12:41:56PM -0700, Jonathan Corbet wrote:
Ever since I updated to post-FC6 rawhide on my x86-64 system, gnome-terminal has been unreliable. It occasionally crashes, often at strange times. I put it into Bugzilla (https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=217378) but have not heard any more - how dare people not fix my bug (for free) within 24 hours?!? :)
I am curious, though, as to whether I'm really the only one who sees this. The problem appears to be related to a memory leak. A quick ps on my system shows:
corbet 14974 0.0 5.4 333732 55532 ? Ssl Nov27 0:13 gnome-terminal
A 300MB address space (50MB resident) is a bit on the hefty side, even considering that we're talking about a GNOME application here. Doing the same thing an hour later shows this:
corbet 14974 0.0 5.0 341236 52032 ? Ssl Nov27 0:14 gnome-terminal
Whereas when I put in the BZ entry I had this:
corbet 14974 0.0 2.3 295520 24288 ? Rsl 07:54 0:02 gnome-terminal
In other words, the thing is growing at a fast and steady rate.
Personally, I think that a terminal emulator should know its place, and gnome-terminal has failed to keep within its bounds. Is this something special it's doing for me, or is it a wider problem?
The memory usage reported by 'ps' or 'top' is essentially /useless/ as a source of information about how much memory is actually used by a program.
On x86_64 in particular, libraries are mapped into memory on very coarse granularity, but the actual usage is nowhere near the map size. A freshly launched gnome-terminal on i386 has a mapped size of 49 MB, while x86_64 it is 430 MB. The actual resident size though is ~20 MB on i386, or 30 MB on x86_64, which is pretty reasonable - particularly when you then look at how much of this is shared vs private mappings.
The size of private mappings in gnome-terminal appears to be principally related to number of tabs / windows open & the scrollback size.
Anyway if you want to examine actual memory maps / usage to get some real memory figures look at /proc/[PID]/smaps rather tha top/ps. That file's rather unpleasent to read, so its useful to post-process it
Here is some top info from my system: ps aux|grep terminal : davidt 3827 2.5 2.6 40380 13608 ? Sl 07:20 0:00 gnome-terminal
top : 3827 davidt 15 0 40380 13m 9692 S 3.3 2.7 0:00.76 gnome-terminal
And an article describing the terms VIRT RES SHR : {gentoo} http://forums.gentoo.org/viewtopic.php?t=175419
DaveT.
Daniel P. Berrange berrange@redhat.com wrote:
The memory usage reported by 'ps' or 'top' is essentially /useless/ as a source of information about how much memory is actually used by a program.
Trust me, I understand that. *Changes* in reported sizes are relevant, however, especially when it is forever growing. It's easy enough to see that the process is bloating up.
Tried mem-monitor, but it tells me "Can't locate Class/MethodMaker.pm".
Thanks,
jon
On Tue, Nov 28, 2006 at 01:31:04PM -0700, Jonathan Corbet wrote:
Daniel P. Berrange berrange@redhat.com wrote:
The memory usage reported by 'ps' or 'top' is essentially /useless/ as a source of information about how much memory is actually used by a program.
Trust me, I understand that. *Changes* in reported sizes are relevant, however, especially when it is forever growing. It's easy enough to see that the process is bloating up.
Guess the key is does it ever go down, when closing tabs/windows, because gnome-terminal has the funky 'one process only' model no matter how many terminal windows are open.
Tried mem-monitor, but it tells me "Can't locate Class/MethodMaker.pm".
Ah, you'll need the perl-Class-MethodMaker RPM. I guess I should really make an RPM of mem-monitor...
Regards, Dan.
On Tue, 2006-11-28 at 19:57 +0000, Daniel P. Berrange wrote:
On Tue, Nov 28, 2006 at 12:41:56PM -0700, Jonathan Corbet wrote:
Ever since I updated to post-FC6 rawhide on my x86-64 system, gnome-terminal has been unreliable. It occasionally crashes, often at strange times. I put it into Bugzilla (https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=217378) but have not heard any more - how dare people not fix my bug (for free) within 24 hours?!? :)
I am curious, though, as to whether I'm really the only one who sees this. The problem appears to be related to a memory leak. A quick ps on my system shows:
corbet 14974 0.0 5.4 333732 55532 ? Ssl Nov27 0:13 gnome-terminal
A 300MB address space (50MB resident) is a bit on the hefty side, even considering that we're talking about a GNOME application here. Doing the same thing an hour later shows this:
corbet 14974 0.0 5.0 341236 52032 ? Ssl Nov27 0:14 gnome-terminal
Whereas when I put in the BZ entry I had this:
corbet 14974 0.0 2.3 295520 24288 ? Rsl 07:54 0:02 gnome-terminal
In other words, the thing is growing at a fast and steady rate.
Personally, I think that a terminal emulator should know its place, and gnome-terminal has failed to keep within its bounds. Is this something special it's doing for me, or is it a wider problem?
The memory usage reported by 'ps' or 'top' is essentially /useless/ as a source of information about how much memory is actually used by a program.
On x86_64 in particular, libraries are mapped into memory on very coarse granularity, but the actual usage is nowhere near the map size. A freshly launched gnome-terminal on i386 has a mapped size of 49 MB, while x86_64 it is 430 MB. The actual resident size though is ~20 MB on i386, or 30 MB on x86_64, which is pretty reasonable - particularly when you then look at how much of this is shared vs private mappings.
The size of private mappings in gnome-terminal appears to be principally related to number of tabs / windows open & the scrollback size.
Anyway if you want to examine actual memory maps / usage to get some real memory figures look at /proc/[PID]/smaps rather tha top/ps. That file's rather unpleasent to read, so its useful to post-process it
Would it be possible to get this into the next release of gnome-system-monitor?
Hi,
Anyway if you want to examine actual memory maps / usage to get some real memory figures look at /proc/[PID]/smaps rather tha top/ps. That file's rather unpleasent to read, so its useful to post-process it
Would it be possible to get this into the next release of gnome-system-monitor?
gnome-system-monitor already reports resident memory usage of programs, and breaks that down into shared and private pieces
I think it also uses the xres extension to tell you how much memory its making the X server use to manage pixmaps, shapes, etc (ala xrestop).
-Ray
On Tue, 2006-11-28 at 19:18 -0500, Ray Strode wrote:
Hi,
Anyway if you want to examine actual memory maps / usage to get some real memory figures look at /proc/[PID]/smaps rather tha top/ps. That file's rather unpleasent to read, so its useful to post-process it
Would it be possible to get this into the next release of gnome-system-monitor?
gnome-system-monitor already reports resident memory usage of programs, and breaks that down into shared and private pieces
does it also account for shared pieces that nobody else is using? Since that false sharing would underestimate the bloat from an app...
Personally, I think that a terminal emulator should know its place, and gnome-terminal has failed to keep within its bounds. Is this something special it's doing for me, or is it a wider problem?
have you run the memprof tool on it (only available in 32 bit :( ).. it is pretty good at finding memory leaks in gnome apps ;)
-
Arjan van de Ven -
Daniel P. Berrange -
David Malcolm -
Development discussions related to Fedora -
Jonathan Corbet -
Matthew Miller -
Ray Strode