Bug 75478

Summary: RH 8.0 gnome-terminal causes severe loading of X server
Product: [Retired] Red Hat Linux Reporter: Rick Richardson <rickrich>
Component: vteAssignee: Ray Strode [halfline] <rstrode>
Status: CLOSED DUPLICATE QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: 8.0CC: bbaetz, dekellum, shishz, 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: 2006-02-21 18:49:47 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:

Description Rick Richardson 2002-10-08 22:16:35 UTC
From Bugzilla Helper:
User-Agent: Mozilla/4.78 [en] (X11; U; Linux 2.4.9-34 i686)

Description of problem:
The gnome-terminal that comes with RH 8.0 can cause the X server to use 50% of
the CPU on a 2Ghz pentium.  The gnome-terminal that was in RH 7.2 did not have
this problem.

How reproducible: Always

Steps to Reproduce:
To reproduce the problem, fire up a gnome-terminal and then run a curses
application inside it that does a fair amount of real-time screen updating.  One
such application is available at http://linuxtrade.0catch.com (which is a
program
I authored).  I like to use a gnome-terminal with 160 columns and 60 or so
lines.
With the new gnome-terminal font selector,I had to use the 8 point monospace
font
to get that many lines/columns on the screen.

Then, just display 30-40 stocks during the trading day.  That will generate a
fair amount of screen updating.  Then, use the "top" command and you will see
that the X server is consuming vaste quantities of CPU.

Repeat the experiment with plain "xterm" or the gnome-terminal from Redhat 7.2,
and you will find that the CPU usage is almost negligible.

-Rick

Comment 1 Rick Richardson 2002-10-15 21:35:31 UTC
Silly me, its way easier to reproduce this bug than what I suggest above.

Simply fire up two gnome-terminals.  Run "top" in one of them, run "vi
/etc/termcap" in the other.  In the "vi" window, repeatedly press ctrl-u ctrl-d
ctrl-u ctrl-d ....  In other words, simply scroll the display up and down.

Even at the slow speed you can type those vi commands, you can drive the X
server to 50% CPU utilization (2Ghz P4).

This really is a terrible regression compared to previous releases of Redhat.  I
personally would consider this to be a "severity 1 can't ship the product" kind
of bug. But I guess its too late for that :-)

-Rick

Comment 2 Victor Martinez 2002-10-18 20:58:21 UTC
With the added problem of the gnome-terminals getting into a state that they 
will no longer accept keyboard input make the gnome-terminal practically 
unusable. I dont have to have something running that continously updates the 
terminals to feel like im running with 1/2 the memory and 1/2 the processor 
speed.


Comment 3 David Kellum 2002-11-04 21:23:19 UTC
I find it even easier to reproduce than original reporter. All I need to do is
simple launch a gnome-terminal, leave it completely alone, and it consumes 100%
CPU (between gnome-terminal and X processes):

  PID USER     PRI  NI  SIZE  RSS SHARE STAT %CPU %MEM   TIME COMMAND
 2180 david     25   0 11124  10M  7116 R    63.2  4.3   1:26 gnome-terminal
  685 root       5 -10 25028  16M  6012 S <  35.5  6.4   7:45 X

This in on a P3 700 Mhz laptop, standard GNOME desktop of stock Redhat 8.0, and
ATI Rage mobility graphics card.

Strace on the gnome-terminal yields this infinite loop:

write(3, "5\30\4\0S\276\333\1\217\0\300\1\7\0\20\0007\0\7\0T\276"..., 356) = 356
read(3, "\1\1Yf\0\0\0\0\16\0\240\1\0\0\0\0\4\0\0\0\0\0\0\0Xzn\10"..., 32) = 32
ioctl(3, 0x541b, [0])                   = 0
gettimeofday({1036444739, 774886}, NULL) = 0
poll([{fd=15, events=POLLIN}, {fd=3, events=POLLIN}, {fd=6, events=POLLIN},
{fd=8, events=POLLIN|POLLPRI}, {fd=9, events=POLLIN|POLLPRI}, {fd=10,
events=POLLIN|POLLPRI}, {fd=11, events=POLLIN|POLLPRI}, {fd=13,
events=POLLIN|POLLPRI}, {fd=12, events=POLLIN|POLLPRI}, {fd=14, events=POLLIN}],
10, 0) = 0
gettimeofday({1036444739, 789154}, NULL) = 0
ioctl(3, 0x541b, [0])                   = 0
poll([{fd=15, events=POLLIN}, {fd=3, events=POLLIN}, {fd=6, events=POLLIN},
{fd=8, events=POLLIN|POLLPRI}, {fd=9, events=POLLIN|POLLPRI}, {fd=10,
events=POLLIN|POLLPRI}, {fd=11, events=POLLIN|POLLPRI}, {fd=13,
events=POLLIN|POLLPRI}, {fd=12, events=POLLIN|POLLPRI}], 9, 0) = 0

Comment 4 Ray Strode [halfline] 2004-11-04 05:25:48 UTC

*** This bug has been marked as a duplicate of 110154 ***

Comment 5 Red Hat Bugzilla 2006-02-21 18:49:47 UTC
Changed to 'CLOSED' state since 'RESOLVED' has been deprecated.