Bug 73156
| Summary: | gnome-terminal leaks memory | ||
|---|---|---|---|
| Product: | [Retired] Red Hat Linux | Reporter: | Felipe Alfaro Solana <felipe_alfaro> |
| Component: | vte | Assignee: | Nalin Dahyabhai <nalin> |
| Status: | CLOSED DUPLICATE | QA Contact: | |
| Severity: | high | Docs Contact: | |
| Priority: | high | ||
| Version: | 8.0 | CC: | felipe_alfaro, rudi, tomg |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | i386 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2006-02-21 18:49:33 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | |||
| Bug Blocks: | 67217, 79578 | ||
|
Description
Felipe Alfaro Solana
2002-08-31 11:46:46 UTC
Should be fixed in newer vte e.g. 0.8.14 (be sure to reopen this if not fixed) I don't see this in vte-0.8.15-1. CLOSING -> RAWHIDE Well, it's not completely fixed... I have tested this with vte-0.8.19-1 and have found it only occurs when running the entire desktop on a Xvnc session: If I run X-Window locally (for example, by entering run level 5, and accessing my session from gdm while using a standard X server), gnome-terminal does not leak memory, although it stays stable at a whopping 11MB of memory (a lot of memory for a terminal). But, if I configure the Xvnc server by modifying "/etc/sysconfig/vncserver" and adding the following line: VNCSERVERS="1:root" then invoke "/etc/init.d/vncserver start" and next use "vncviewer" from my laptop, when I see the remote desktop and launch "gnome-terminal", it *does* leak memory as described in the bug report. I'm still seeing a leak myself (vte-0.8.19-1, built from SRPM). If I start
xcdroast from a gnome-terminal and create a CD, almost all of my memory is used
up in the process.
[root@gemini root]# xcdroast &
[1] 619
[root@gemini root]#
** WARNING **: The X-CD-Roast wrapper seems not to have the correct
permissions set
** WARNING **: So do as root something like that:
chown root:cdwrite /usr/lib/xcdroast-0.98/bin/xcdrwrap;
chmod 2755 /usr/lib/xcdroast-0.98/bin/xcdrwrap
** WARNING **: For more information read
/usr/share/doc/xcdroast-0.98a9/README.nonroot
*** NOTE ***:
---------------------------------------------------------------
This permission warning and the following set-uid bit warnings
can be safely ignored, if you want to run X-CD-Roast as root only.
---------------------------------------------------------------
[1]+ Done xcdroast
[root@gemini root]# free
total used free shared buffers cached
Mem: 1031032 837548 193484 0 20160 739176
-/+ buffers/cache: 78212 952820
Swap: 1052216 0 1052216
*** Bug 75498 has been marked as a duplicate of this bug. *** *** Bug 75498 has been marked as a duplicate of this bug. *** there are a whole family of this one out there... bug 73226: gnome-terminal has serious memory leak (even when idle) bug 74972: Memory leak in gnome-terminal bug 75270: Incredibly bad memory leaks in gnome-terminal, causing entir.. [] bug 76219: gnome-terminal memory leak bug 76410: memory leak causes swap file to max and crashes system They are all about the same issue. Perhaps they should be made duplicates of this bug? If ftp://people.redhat.com/hp/testing/ fixes the problem it's an Xft bug and can be closed (consider marking dup of 76219 or vice versa) dark@c2i, thanks a lot for finding those dups, it really does save us a lot of time. appreciated. Havoc's Xft-2.0.4 fixed this for me. A 'top' running on a vncviewer'd gnome-terminal now behaves as it should, and the memory usage of individual terms once their scrollback buffers are full seems stable. We have been running this for a few weeks now, with all functioning correctly via remote xdm sessions. Thanks *** This bug has been marked as a duplicate of 76219 *** Changed to 'CLOSED' state since 'RESOLVED' has been deprecated. |