Bug 81018

Summary: gnome-terminal fully utilizes CPU
Product: [Retired] Red Hat Linux Reporter: Braden McDaniel <braden>
Component: vteAssignee: Nalin Dahyabhai <nalin>
Status: CLOSED WORKSFORME QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: 9CC: gczarcinski, giorgio.bersano, jroyse, michael, wtogami
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: 2003-09-26 22:18:03 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: 100644    

Description Braden McDaniel 2003-01-03 15:35:29 UTC
Description of problem:
gnome-terminal fully utilizes a CPU when it's doing nothing.

Version-Release number of selected component (if applicable):
2.1.3-2

How reproducible:
Consistently.

Comment 1 Braden McDaniel 2003-01-03 15:40:34 UTC
Hm. This was a problem yesterday, and a problem earlier this morning. After
logging out and logging back in, I'm no longer seeing it.


Comment 2 Need Real Name 2003-01-04 07:06:57 UTC
I consistently see this too.  I have my session set up to bring up two
gnome-terminals when I log in, on different workspaces.  Until I switch to the
second workspace, something is using all the CPU.  The first gnome-terminal is
displayed and active when I log in.  Switching to the second workspace, causing
the second gnome-terminal to be displayed and active, makes the CPU usage drop back.

Comment 3 Warren Togami 2003-01-06 06:58:56 UTC
If you run "xterm" then "gnome-terminal" within that, do you see any messages in
the xterm window?


Comment 4 Need Real Name 2003-01-06 22:36:19 UTC
I updated glibc to 2.3.1-30 and XFree86 to 4.2.99.3-20021230.0, from RedHat
Rawhide, and now the problem is gone.

Comment 5 Gene Czarcinski 2003-01-07 17:25:33 UTC
I am also seeing this on restart (three gnome-terminal sessions running).  If I
kill the sessions and restart them everything is OK

Comment 6 Need Real Name 2003-01-07 17:39:01 UTC
Oops, I spoke too soon.  I still see this problem even with the updated glibc
and XFree86.  As to Warren Togami's question, starting a gnome-terminal from an
xterm does not produce any messages (error or otherwise) in the xterm.

Comment 7 Bill Nottingham 2003-01-14 03:47:07 UTC
Please try vte-0.10.9; this may fix it for you.

Comment 8 Need Real Name 2003-01-14 16:39:18 UTC
I have upgraded to vte-0.10.10-1 from rawhide.  The problem seems to have gone
away--it would almost always (always?) happen the first time I log in after
booting, and I rebooted and logged in without seeing it.

Comment 9 G. Bersano 2003-04-03 09:11:14 UTC
*** Bug 87779 has been marked as a duplicate of this bug. ***

Comment 10 Warren Togami 2003-07-30 23:20:17 UTC
gnome-terminal continues to use lots of CPU in rendering text as it flies by
quickly, but it no longer has the RENDER-less X server huge CPU and memory usage
bug since at least Shrike.  I would recommend closing this bug unless you can
still reproduce it.

Comment 11 Michael Lee Yohe 2003-08-21 22:30:06 UTC
Confirming that recent versions of vte are a bit better when it comes to being
idle and not affecting CPU utilization.

Perhaps we should change "gnome-terminal fully utilizes CPU" to "vte uses
massive amounts of CPU when using AA fonts"...?

Comment 12 Warren Togami 2003-08-22 00:11:15 UTC
There were two separate gnome-terminal issues during the last beta cycle:
1) Lack of XRENDER caused huge CPU usage, quickly growing memory, swap storm and
eventually OOM.  This was fixed before the release of Shrike.
2) When AA text flies by quickly in a gnome-terminal on certain video cards, it
uses massive amounts of CPU making it far slower than xterm or konsole.

The current title "gnome-terminal fully utilizes CPU" is indicative of #1,
because #2 wouldn't use CPU during inactivity.

Comment 13 Braden McDaniel 2003-09-26 22:18:03 UTC
The problem I originally reported went away some time ago.