GNOME Bugzilla – Bug 163814
gnome-terminal crash when using when TERM is not set correctly
Last modified: 2007-07-03 16:48:40 UTC
Steps to reproduce: 1. launch a terminal emulation program such as minicom in a gnome-terminal with default TERM value set to xterm 2. gnome-terminal exit immediatly 3. Stack trace: error output: ** ERROR **: file vte.c: line 7609 (vte_terminal_process_incoming): assertion failed: ((_vte_buffer_length(terminal->pvt->incoming) > 0) || (terminal->pvt->pending->len > 0)) aborting... This is not a segfault, there is no core generated. setting TERM to vt100 prevent gnome-terminal to exit. Other information:
That assertion matches bug 120075. What is your version of gnome-terminal and more importantly vte (might be named libvte or libvte4)?
this is mandrake cooker. [guillaume@pomerol TIA2005]$ rpm -q libvte4 libvte4-0.11.11-4mdk
I also run Mandrake Cooker, but cannot reproduce this. I don't have a modem, so I only go into minicom and exit minicom right after that. Does it also crash with Mutt? It might be caused by one of the performance patches Mandrake applies. Can you try to disable those and retry? You can run "gnome-terminal --disable-factory" to ensure gnome-terminal starts a separate instance (so when it crashes it doesn't take all other gnome-terminal windows with it & also to ensure a new vte is loaded).
Can't reproduce this on Fedora Core 3 either.
It seems to be caused by a perf improvement in Mandrake vte package, referenced as GNOME bug #143914. Just disabling it is enough to fix the issue. And mutt is immune to the problem.
Søren, any idea what in your patch could cause this problem?
Well, my patch did change various things around wrt. the process_incoming() function. Maybe this causes it to be called with an empty input buffer or something.
I get this assertion as well (ibuild build of gnome 2.9 on Debian unstable) with the latest vte/gnome-terminal. The culprit seems to be one of the performance patches.
I can reproduce this and it also doesn't crash when TERM=vt100 here. This is with the package from fedora core and I guess now also the same for CVS since that has the same patches. Two possibilities: - The app causes some weird situation to happen with the terminal that it doesn't handle correctly - One of the patches are doing something to cause this - The assertion is not valid any longer because of other changes Here's what I see: ** ERROR **: file vte.c: line 7602 (vte_terminal_process_incoming): assertion failed: ((_vte_buffer_length(terminal->pvt->incoming) > 0) || (terminal->pvt->pending->len > 0)) aborting... But before this I see these kinds of warnings: ** (gnome-terminal:13608): WARNING **: DECSET/DECRESET mode 12 not recognized, ignoring. I added a fprintf statement which shows that this only crashes when *both* of these are '0', but everything is fine when one or the other is '0': incoming is 0, pending->len is 0
Created attachment 38164 [details] [review] A fix I can reproduce the problem now that I have updated to cvs HEAD. Here is a patch that fixes it, by not processing incoming data when there are no data to process (which is the assertion that gets triggered). Whether it is a better fix to instead make sure the display/coalesce timeouts are never installed when there are no data to process, is a question that would have to be decided by a maintainer, should such a person appear.
Ok, let's go with this for now and see if there's a cleaner or more correct way to fix the problem later on.
Btw, have you tried catting a lot of text in g-t with this patch? It makes the text go by in batches and it doesn't look like it's scrolling at all, it's showing a screenfull of text, then it waits and shows a random new one, and so on. Bad regression IMO
*** Bug 160759 has been marked as a duplicate of this bug. ***
Ok, I've experimented a bit with the values for the coalesce timeout and display timeout. I tried to find values that made us behave similar to xterm when it comes to what flies by on screen and at the same time let the terminal be fast. So, using 2 ms for both timeouts gives us something that looks similar to xterm when cat'ing (used -u8 -fa Monospace -fs 10 to get the same settings as g-t) and still is a bit faster cat'ing the same amount of text. I'll commit this and close this bug. New tarball will be uploaded to ftp.gnome.org soon.
Forgot to close this it seems.
*** Bug 162433 has been marked as a duplicate of this bug. ***
*** Bug 453333 has been marked as a duplicate of this bug. ***