CPU-bound looping seen in gnome-terminal
Submitted by Dafydd Harries
Link to original bug (#126443)
Description
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` 0x40a41b37 in g_array_maybe_expand (array=0x84754fc, len=1) at garray.c:345
`#1` 0x40a413ec in g_array_append_vals (farray=0x84754fc, data=0x0, len=1)
at garray.c:138
`#2` 0x4042c7a8 in vte_g_array_fill (array=0x84754fc, item=0x819f334,
final_size=101) at vte.c:508
`#3` 0x4042c941 in vte_new_row_data_sized (terminal=0x819ea88, fill=1)
at vte.c:534
`#4` 0x40430dbf in vte_terminal_ensure_cursor (terminal=0x819ea88, current=0)
at vte.c:2859
`#5` 0x404362c1 in vte_terminal_insert_char (terminal=0x819ea88, c=91,
force_insert_mode=0, invalidate_now=0, paint_cells=1, ensure_after=0,
forced_width=0) at vte.c:6703
`#6` 0x40437b86 in vte_terminal_process_incoming (data=0x819ea88) at vte.c:7488
`#7` 0x40a5aa2c in g_timeout_dispatch (source=0x8483410, callback=0x27,
user_data=0x0) at gmain.c:3125
`#8` 0x40a57ecd in g_main_dispatch (context=0x80bcf78) at gmain.c:1752
`#9` 0x40a58f98 in g_main_context_dispatch (context=0x80bcf78) at gmain.c:2300
`#10` 0x40a592d0 in g_main_context_iterate (context=0x80bcf78, block=1,
dispatch=1, self=0x80bfab8) at gmain.c:2381
`#11` 0x40a59a31 in g_main_loop_run (loop=0x80bd458) at gmain.c:2601
`#12` 0x406c7f77 in gtk_main () at gtkmain.c:1129
`#13` 0x0805e4f7 in main (argc=1, argv=0xbffffbb4) at terminal.c:1588
Backtraces similar to the above one appeared repeatedly.
`#0` 0x40a41b1a in g_array_maybe_expand (array=0x8498c8c, len=1) at garray.c:341
`#1` 0x40a413ec in g_array_append_vals (farray=0x8498c8c, data=0x819f334, len=1)
at garray.c:138
`#2` 0x4042c7a8 in vte_g_array_fill (array=0x8498c8c, item=0x819f334,
final_size=101) at vte.c:508
`#3` 0x4042c941 in vte_new_row_data_sized (terminal=0x819ea88, fill=1)
at vte.c:534
`#4` 0x40430dbf in vte_terminal_ensure_cursor (terminal=0x819ea88, current=0)
at vte.c:2859
`#5` 0x404362c1 in vte_terminal_insert_char (terminal=0x819ea88, c=91,
force_insert_mode=0, invalidate_now=0, paint_cells=1, ensure_after=0,
forced_width=0) at vte.c:6703
`#6` 0x40437b86 in vte_terminal_process_incoming (data=0x819ea88) at vte.c:7488
`#7` 0x40a5aa2c in g_timeout_dispatch (source=0x8483410, callback=0x45,
user_data=0x819f334) at gmain.c:3125
`#8` 0x40a57ecd in g_main_dispatch (context=0x80bcf78) at gmain.c:1752
`#9` 0x40a58f98 in g_main_context_dispatch (context=0x80bcf78) at gmain.c:2300
`#10` 0x40a592d0 in g_main_context_iterate (context=0x80bcf78, block=1,
dispatch=1, self=0x80bfab8) at gmain.c:2381
`#11` 0x40a59a31 in g_main_loop_run (loop=0x80bd458) at gmain.c:2601
`#12` 0x406c7f77 in gtk_main () at gtkmain.c:1129
`#13` 0x0805e4f7 in main (argc=1, argv=0xbffffbb4) at terminal.c:1588
This was also a common theme.
`#0` 0x40b29f9f in memcpy () from /lib/tls/libc.so.6
`#1` 0x00000001 in ?? ()
`#2` 0x08430134 in ?? ()
`#3` 0x40a41411 in g_array_append_vals (farray=0x8503b28, data=0x8,
len=135918388) at garray.c:140
`#4` 0x4042c7a8 in vte_g_array_fill (array=0x8430134, item=0x819f334,
final_size=101) at vte.c:508
`#5` 0x4042c941 in vte_new_row_data_sized (terminal=0x819ea88, fill=1)
at vte.c:534
`#6` 0x4042f727 in vte_insert_line_internal (terminal=0x819ea88,
position=18636006) at vte.c:2017
`#7` 0x404347d1 in vte_sequence_handler_delete_lines (terminal=0x819ea88,
match=0x81a2f50 "delete-lines", match_quark=833, params=0x8503b28)
at vte.c:5277
`#8` 0x40436785 in vte_terminal_handle_sequence (widget=0x819ea88,
match_s=0x81a2f50 "delete-lines", match=833, params=0x8) at vte.c:6891
`#9` 0x40437764 in vte_terminal_process_incoming (data=0x819ea88) at vte.c:7415
`#10` 0x40a5aa2c in g_timeout_dispatch (source=0x819bd68, callback=0x8503b28,
user_data=0x8) at gmain.c:3125
`#11` 0x40a57ecd in g_main_dispatch (context=0x80bcf78) at gmain.c:1752
`#12` 0x40a58f98 in g_main_context_dispatch (context=0x80bcf78) at gmain.c:2300
`#13` 0x40a592d0 in g_main_context_iterate (context=0x80bcf78, block=1,
dispatch=1, self=0x80bfab8) at gmain.c:2381
`#14` 0x40a59a31 in g_main_loop_run (loop=0x80bd458) at gmain.c:2601
`#15` 0x406c7f77 in gtk_main () at gtkmain.c:1129
`#16` 0x0805e4f7 in main (argc=1, argv=0xbffffbb4) at terminal.c:1588
I think this is the one I saw most of all.
`#0` g_array_sized_new (zero_terminated=0, clear=0, elt_size=139472504,
reserved_size=101) at garray.c:102
`#1` 0x4042c8fd in vte_new_row_data_sized (terminal=0x819ea88, fill=1)
at vte.c:529
`#2` 0x40430dbf in vte_terminal_ensure_cursor (terminal=0x819ea88, current=0)
at vte.c:2859
`#3` 0x404362c1 in vte_terminal_insert_char (terminal=0x819ea88, c=91,
force_insert_mode=0, invalidate_now=0, paint_cells=1, ensure_after=0,
forced_width=0) at vte.c:6703
`#4` 0x40437b86 in vte_terminal_process_incoming (data=0x819ea88) at vte.c:7488
`#5` 0x40a5aa2c in g_timeout_dispatch (source=0x848eb20, callback=0x8502e78,
user_data=0x8502e78) at gmain.c:3125
`#6` 0x40a57ecd in g_main_dispatch (context=0x80bcf78) at gmain.c:1752
`#7` 0x40a58f98 in g_main_context_dispatch (context=0x80bcf78) at gmain.c:2300
`#8` 0x40a592d0 in g_main_context_iterate (context=0x80bcf78, block=1,
dispatch=1, self=0x80bfab8) at gmain.c:2381
`#9` 0x40a59a31 in g_main_loop_run (loop=0x80bd458) at gmain.c:2601
`#10` 0x406c7f77 in gtk_main () at gtkmain.c:1129
`#11` 0x0805e4f7 in main (argc=1, argv=0xbffffbb4) at terminal.c: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.
Version: 0.11.x
Resolution: RESOLVED FIXED