GNOME Bugzilla – Bug 117945
vte hangs often when using screen
Last modified: 2008-11-26 12:21:41 UTC
Distribution: Unknown Package: vte Severity: major Version: GNOME2.3.4 0.11.x Gnome-Distributor: GNOME.Org Synopsis: vte hangs often Bugzilla-Product: vte Bugzilla-Component: VteTerminal Bugzilla-Version: 0.11.x Description: Description of the crash: gnome-terminal (by way of vte) hangs often. One such means is to ssh to a host and run pine. Eventually (it seems after a limited amount of inactivity at the keyboard), gnome-terminal will hang. I ran gdb on gnome-terminal, and this is what I've got: 0x40bf27d1 in g_array_maybe_expand () from /usr/lib/libglib-2.0.so.0 (gdb) Single stepping until exit from function g_array_maybe_expand, which has no line number information. 0x40bf1fda in g_array_sized_new () from /usr/lib/libglib-2.0.so.0 (gdb) Single stepping until exit from function g_array_sized_new, which has no line number information. 0x405f341e in vte_new_row_data_sized () from /usr/lib/libvte.so.4 (gdb) Single stepping until exit from function vte_new_row_data_sized, which has no line number information. 0x405f61b0 in vte_insert_line_internal () from /usr/lib/libvte.so.4 (gdb) Single stepping until exit from function vte_insert_line_internal, which has no line number information. 0x405f84cf in vte_sequence_handler_sf () from /usr/lib/libvte.so.4 (gdb) Single stepping until exit from function vte_sequence_handler_sf, which has no line number information. and it's hung at vte_sequence_handler_sf. 0x405f84cf in vte_sequence_handler_sf () from /usr/lib/libvte.so.4 (gdb) Single stepping until exit from function vte_sequence_handler_sf, which has no line number information. ------- Bug moved to this database by unknown@bugzilla.gnome.org 2003-07-20 19:00 ------- Reassigning to the default owner of the component, nalin@redhat.com.
I'd like the priority of this bug to be stepped up. It severely limits my ability to get work done, and it happens very very easily. When I use xterm, I have never run into a similar problem, but when I use gnome-terminal (latest as of today, but always latest as of end-of-day) I run into the bug perhaps a dozen or more times in a 2-3 hour session. Pine seems to be the easiest way to trigger the bug, especially involving highlighted text and fast scrolling.
Is this still happening with 2.4/2.5 series?
Yes. It doesn't seem to be happening as often, but many times I've recognized the "signs" that it's about to weird out and I take action. Here's what I do: I notice that much of the terminal is "missing" (completely black). I use 'screen' very frequently, and running the "redisplay" command sometimes, but not always, fixes it. This usually happens when viewing a message index in pine and scrolling up or down using the arrow keys, and scrolling very fast. When it goes to a new "page" I get this behavior. When the terminal starts doign the "not painting" thing more frequently, I know there is a very good chance it will hang shortly. What's odd here is that if I exit pine and start it up again, things work fine for a while again. Pine just uses curses, and I can run pine for *weeks* at a time in an xterm without other problems, so the blame must lie with vte and/or gnome-terminal. My basic debugging efforts short that it's in vte, however. What would you like me to do? I'd *love* to have this bug resolved. I am positive it is related to the "not painting" behavior I see.
Yes, I've tried gnome-terminal with screen, and it usually screws up, I didn't get any crash, because I switched gnome-teminal -> ssh -> screen -> 3 shells to: gnome-terminal -> tab -> ssh -> tab -> ssh -> tab -> ssh But this is not a solution, so marking high priority. BTW if you can gdb gnome-terminal with debuggins symbols and source code, you'll get a more usefull stack trace. If so, please, attach it here.
Here's another stack trace.
+ Trace 44189
Reporter has provided good information, marking NEW to move this forward.
This bug reported against gnome-terminal is a duplicate of this bug. It also has a stack trace in the comments. http://bugzilla.gnome.org/show_bug.cgi?id=140289
Another couple of stack traces... Fedora Core 2: % rpm -q gnome-terminal vte gnome-terminal-2.6.0-2 vte-0.11.10-5.1 -----------------------
+ Trace 49997
----------------------- Going after it with gdb tells me that it's stuck in this loop.... In vte.c in the function vte_insert_line_internal: /* Pad out the line data to the insertion point. */ while (_vte_ring_next(terminal->pvt->screen->row_data) < position) { row = vte_new_row_data_sized(terminal, TRUE); _vte_ring_append(terminal->pvt->screen->row_data, row); } (gdb) print terminal->pvt->screen->row_data->delta + terminal->pvt->screen->row_data->length $7 = 515507842 (gdb) print position $8 = 543584853 Somehow, position ended up being somewhere upwards of 518 * 2^20. And that seems rather large. I'm not sure how much scrollback I have, but it's definitely not more than 2000 lines. Of course, I'm not sure what position means there.
More stuff.... vte.c: vte_terminal_handle_sequence It calls g_tree_lookup to get a handler function. Then if it found one, it does: handler(terminal, match_s, match, params); (gdb) print terminal, match_s, match, params $15 = (GValueArray *) 0x89cb8f8 (gdb) print terminal $16 = (VteTerminal *) 0x8a869c8 (gdb) print match_s $17 = 0x86b31d8 "delete-lines" (gdb) print match $18 = 917 (gdb) print params $19 = (GValueArray *) 0x89cb8f8 (gdb) print params[0] $20 = {n_values = 144492004, values = 0x0, n_prealloced = 0} (gdb) down
+ Trace 49998
So, the arguments the handler function gets are not exactly the same as were passed in. Of course, that could be the optimizer's doing. I caught the function after it had been running a good long while. Anyway, enough debugging unless I actually have a patch to submit.
*** Bug 138866 has been marked as a duplicate of this bug. ***
I'm using vte as a component in my own program (http://yaog.sf.net/), and I constantly get a similar freeze. I noted that it appears when the vte_terminal_feed_child-function has been called. If I commented out the call to vte_terminal_feed_child, vte doesn't hang. Input from keyboard doesn't hang vte. Vte does not consume the CPU when hung. The child process still works, it just doesn't get anything from its stdin. I've seen this on RHEL 3 and 4, a Debian, a generic GNU and MacOSX. HTH, Kalle
As much as I hate to "me too", I'm seeing this same behavior with vte-0.11.13-r2 and xfce terminal 0.2.4 from gentoo. It's happened quite a few times. The terminal tab stops paying attention to stdin. I know it's not completely frozen because i can send a "wall" message that shows up. This has only ever happened when I'm connected over ssh. That's about half the time I'm using it, so it's statistically significant. It doesn't happen quite often enough (heh) but I've rebuilt terminal and vte with debugging in the hopes that I'll get a chance to get a new backtrace.
* Tries to attract the attention of anyone who can still reproduce this bug. I checked vte_sequence_handler_delete_lines() [as mentioned above] and found its use of the GValue inconsistent with the majority of the other sequence handlers - it was missing a type check. So I corrected that; and I ask for people to check trunk/HEAD in order to see if they can reproduce the crash. r1598: 2007-01-31 Chris Wilson <chris@chris-wilson.co.uk> In a few places the contents of a GValue were being used without checking that they were of the expected type. cf Bug 117945 which mentions stack corruption inside vte_sequence_handler_delete_lines() - one of the corrected instances. * src/vteseq.c: (vte_sequence_handler_al), (vte_sequence_handler_cs), (vte_sequence_handler_cS), (vte_sequence_handler_dl), (vte_sequence_handler_character_attributes), (vte_sequence_handler_insert_lines), (vte_sequence_handler_delete_lines), (vte_sequence_handler_device_status_report), (vte_sequence_handler_dec_device_status_report): Check that the GValue holds a long before dereference.
Closing old NEEDINFO bugs. I think we can safely assume this is fixed.