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 163814 - gnome-terminal crash when using when TERM is not set correctly
gnome-terminal crash when using when TERM is not set correctly
Status: RESOLVED FIXED
Product: vte
Classification: Core
Component: general
0.10.x
Other All
: High critical
: ---
Assigned To: VTE Maintainers
VTE Maintainers
: 160759 162433 453333 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2005-01-12 14:42 UTC by Guillaume Rousse
Modified: 2007-07-03 16:48 UTC
See Also:
GNOME target: ---
GNOME version: 2.7/2.8


Attachments
A fix (1.87 KB, patch)
2005-03-02 18:13 UTC, Soren Sandmann Pedersen
none Details | Review

Description Guillaume Rousse 2005-01-12 14:42:01 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:
Comment 1 Olav Vitters 2005-01-12 23:08:04 UTC
That assertion matches bug 120075. What is your version of gnome-terminal and
more importantly vte (might be named libvte or libvte4)?
Comment 2 Guillaume Rousse 2005-01-13 10:34:31 UTC
this is mandrake cooker.

[guillaume@pomerol TIA2005]$ rpm -q libvte4
libvte4-0.11.11-4mdk
Comment 3 Olav Vitters 2005-01-13 23:26:58 UTC
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).
Comment 4 Kjartan Maraas 2005-02-15 11:05:58 UTC
Can't reproduce this on Fedora Core 3 either.
Comment 5 Guillaume Rousse 2005-02-15 17:02:25 UTC
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.
Comment 6 Kjartan Maraas 2005-02-15 21:18:30 UTC
Søren, any idea what in your patch could cause this problem?
Comment 7 Soren Sandmann Pedersen 2005-02-17 16:31:36 UTC
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. 

Comment 8 Richard Hult 2005-03-02 09:35:16 UTC
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.
Comment 9 Kjartan Maraas 2005-03-02 12:25:28 UTC
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
Comment 10 Soren Sandmann Pedersen 2005-03-02 18:13:32 UTC
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.
Comment 11 Kjartan Maraas 2005-03-02 21:00:49 UTC
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.
Comment 12 Kjartan Maraas 2005-03-02 21:08:28 UTC
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
Comment 13 Kjartan Maraas 2005-03-02 22:43:47 UTC
*** Bug 160759 has been marked as a duplicate of this bug. ***
Comment 14 Kjartan Maraas 2005-03-02 22:47:13 UTC
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.
Comment 15 Kjartan Maraas 2005-07-03 20:24:41 UTC
Forgot to close this it seems.
Comment 16 Chris Wilson 2007-01-31 15:23:50 UTC
*** Bug 162433 has been marked as a duplicate of this bug. ***
Comment 17 palfrey 2007-07-03 16:48:40 UTC
*** Bug 453333 has been marked as a duplicate of this bug. ***