After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 126443 - CPU-bound looping seen in gnome-terminal
CPU-bound looping seen in gnome-terminal
Status: RESOLVED FIXED
Product: vte
Classification: Core
Component: general
0.11.x
Other Linux
: Normal normal
: ---
Assigned To: VTE Maintainers
VTE Maintainers
Depends on:
Blocks:
 
 
Reported: 2003-11-07 15:06 UTC by Dafydd Harries
Modified: 2006-02-14 06:38 UTC
See Also:
GNOME target: ---
GNOME version: 2.9/2.10



Description Dafydd Harries 2003-11-07 15:06:26 UTC
Every so often, gnome-terminal starts consuming 100% CPU and stops
responding to expose events. It doesn't seem to be triggered by anything in
particular. I tried attaching gdb to a g-t process exhibiting this
behaviour and getting some backtraces at various intervals. My guess is
that it's a problem with vte rather than g-t.

  • #0 g_array_maybe_expand
    at garray.c line 345
  • #1 g_array_append_vals
    at garray.c line 138
  • #2 vte_g_array_fill
    at vte.c line 508
  • #3 vte_new_row_data_sized
    at vte.c line 534
  • #4 vte_terminal_ensure_cursor
    at vte.c line 2859
  • #5 vte_terminal_insert_char
    at vte.c line 6703
  • #6 vte_terminal_process_incoming
    at vte.c line 7488
  • #7 g_timeout_dispatch
    at gmain.c line 3125
  • #8 g_main_dispatch
    at gmain.c line 1752
  • #9 g_main_context_dispatch
    at gmain.c line 2300
  • #10 g_main_context_iterate
    at gmain.c line 2381
  • #11 g_main_loop_run
    at gmain.c line 2601
  • #12 gtk_main
    at gtkmain.c line 1129
  • #13 main
    at terminal.c line 1588
  • #0 g_array_maybe_expand
    at garray.c line 341
  • #1 g_array_append_vals
    at garray.c line 138
  • #2 vte_g_array_fill
    at vte.c line 508
  • #3 vte_new_row_data_sized
    at vte.c line 534
  • #4 vte_terminal_ensure_cursor
    at vte.c line 2859
  • #5 vte_terminal_insert_char
    at vte.c line 6703
  • #6 vte_terminal_process_incoming
    at vte.c line 7488
  • #7 g_timeout_dispatch
    at gmain.c line 3125
  • #8 g_main_dispatch
    at gmain.c line 1752
  • #9 g_main_context_dispatch
    at gmain.c line 2300
  • #10 g_main_context_iterate
    at gmain.c line 2381
  • #11 g_main_loop_run
    at gmain.c line 2601
  • #12 gtk_main
    at gtkmain.c line 1129
  • #13 main
    at terminal.c line 1588
  • #0 memcpy
    from /lib/tls/libc.so.6
  • #1 ??
  • #2 ??
  • #3 g_array_append_vals
    at garray.c line 140
  • #4 vte_g_array_fill
    at vte.c line 508
  • #5 vte_new_row_data_sized
    at vte.c line 534
  • #6 vte_insert_line_internal
    at vte.c line 2017
  • #7 vte_sequence_handler_delete_lines
    at vte.c line 5277
  • #8 vte_terminal_handle_sequence
    at vte.c line 6891
  • #9 vte_terminal_process_incoming
    at vte.c line 7415
  • #10 g_timeout_dispatch
    at gmain.c line 3125
  • #11 g_main_dispatch
    at gmain.c line 1752
  • #12 g_main_context_dispatch
    at gmain.c line 2300
  • #13 g_main_context_iterate
    at gmain.c line 2381
  • #14 g_main_loop_run
    at gmain.c line 2601
  • #15 gtk_main
    at gtkmain.c line 1129
  • #16 main
    at terminal.c line 1588
  • #0 g_array_sized_new
    at garray.c line 102
  • #1 vte_new_row_data_sized
    at vte.c line 529
  • #2 vte_terminal_ensure_cursor
    at vte.c line 2859
  • #3 vte_terminal_insert_char
    at vte.c line 6703
  • #4 vte_terminal_process_incoming
    at vte.c line 7488
  • #5 g_timeout_dispatch
    at gmain.c line 3125
  • #6 g_main_dispatch
    at gmain.c line 1752
  • #7 g_main_context_dispatch
    at gmain.c line 2300
  • #8 g_main_context_iterate
    at gmain.c line 2381
  • #9 g_main_loop_run
    at gmain.c line 2601
  • #10 gtk_main
    at gtkmain.c line 1129
  • #11 main
    at terminal.c line 1588

This one I only noticed once or twice.

Of course, this is a rather hit-and-miss approach to finding the problem,
as the sample set is quite small.
Comment 1 Dafydd Harries 2004-03-16 00:26:03 UTC
This is still happening with gnome-terminal 2.5.90. It seems to be
particularly susceptible to the bug when I use the "screen" program
over ssh, but that may be a coincidence. I also find when using screen
that the display often becomes garbled and I need to request a redraw,
which cleans it up.

Sometimes, waiting or pressing Ctrl-PageUp repeatedly seems to fix it,
but once it happens, it's usually not very long before it happens
again, and before long g-t becomes unusable.
Comment 2 Bill 2004-09-16 15:08:51 UTC
I'm seeing related stuff, which I've reported in bug #151680 ("gnome terminal
crash").  I'm also seeing elevated CPU usage (often around 40% on P4 2600 cpu).
 I'm also using screen over ssh.
Comment 3 Bill 2004-09-16 16:18:52 UTC
I ran a few tests.  The CPU usage doesn't appear gnome-terminal dependent.  It's
just a matter of how much data is being dumped to the terminal, and seems the
same as xterm.  screen doesn't seem to make much difference.  ssh does make some
difference.  A local "ls -R /" seems to generate half the CPU usage by the
terminal than a remote (ssh) "ls -R /" does.
Comment 4 Mary Gardiner 2004-09-22 18:56:22 UTC
I have the same behaviour.

The trigger for me is known, although not absolutely reproducible. It is the
combination of gnome-terminal, screen and irssi.

These three have a reasonable well known problem involving irssi rendering
badly: basically it turns the entire terminal blue rather than rendering an IRC
channel window. In my particular case, it also inspires this "consume 100% CPU
for a long period of time" (long is between 20 seconds and 10 minutes, CPUs have
been 667MHz PIII, 1.6GHz Celeron and 1.6GHz Centrino).

I can generally cause it to happen within an hour of starting using irssi inside
a screen session on gnome-terminal, but I haven't found a set of keystrokes that
replicate it.
Comment 5 Kjartan Maraas 2005-08-29 11:57:08 UTC
Can you still reproduce this using the latest release of vte?
Comment 6 Dafydd Harries 2005-09-09 14:43:38 UTC
I haven't observed this behaviour for some time, so feel free to close the bug
for now.
Comment 7 Behdad Esfahbod 2006-02-14 06:38:50 UTC
I've not seen it for a long time either.  And I've fixed a couple things recently that may have caused similar behavior.  Closing for now.  Reopen if you can observe with HEAD.