Bug 75478 - RH 8.0 gnome-terminal causes severe loading of X server
RH 8.0 gnome-terminal causes severe loading of X server
Status: CLOSED DUPLICATE of bug 110154
Product: Red Hat Linux
Classification: Retired
Component: vte (Show other bugs)
8.0
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Ray Strode [halfline]
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2002-10-08 18:16 EDT by Rick Richardson
Modified: 2007-04-18 12:47 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-02-21 13:49:47 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Rick Richardson 2002-10-08 18:16:35 EDT
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 17:35:31 EDT
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 16:58:21 EDT
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 16:23:19 EST
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 00:25:48 EST

*** This bug has been marked as a duplicate of 110154 ***
Comment 5 Red Hat Bugzilla 2006-02-21 13:49:47 EST
Changed to 'CLOSED' state since 'RESOLVED' has been deprecated.

Note You need to log in before you can comment on or make changes to this bug.