Bug#862591: libvte-2.91-0: xfce4-terminal crashes when dumping a lot of text

[Brian Warner]

On 5/15/17 7:33 AM, Andreas Henriksson wrote:

> fwiw, I'm not able to reprocude this on amd64 with gnome-terminal.

I wonder if it's somehow specific to this chromebook. I'm running a
thing called "crouton", which gives you a chroot (of sid, in this case,
but you can get various other debian/ubuntu releases too). The X server
that the terminal program is using will send all its pixels to a Chrome
extension that draws them into a web frame. I don't *think* any of that
should be visible to the application, but maybe drawing pixels doesn't
happen as fast as it would on a normal computer?

> In other words, this assertion fails:
> http://sources.debian.net/src/vte2.91/0.46.1-1/src/vtestream-file.h/#L790
> 
>         z_ret = uncompress ((Bytef *) dst, &dstlen_ulongf, (const Bytef *) src, srclen);
>         g_assert_cmpuint (z_ret, ==, Z_OK);
> 
> Would be great if you could confirm by posting the asserting message
> that the application outputs when crashing.

I ran lilyterm from a non-crashing terminal (xterm) and had it dump a MB
of "a"s, and got:


Vte:ERROR:/home/warner/stuff/debian/vte2.91-0.46.1/./src/vtestream-file.h:790:unsigned
int _vte_boa_uncompress(char*, unsigned int, const char*, unsigned int):
assertion failed (z_ret == Z_OK): (4294967293 == 0)

and a coredump. So yes, I think that matches.

(I'm using lilyterm because I wasn't able to get gnome-terminal to run
from a regular shell.. I assume that it wants to be launched from some
special GNOME mode where it gets a control socket or a D-Bus thing or
something).

> Seems to me like you need to seek the answer to why uncompress fails
> in the zlib library.... (Possibly vte could handle the error more
> gracefully but probably a good idea to find out why zlib uncompress
> fails first.)

Yup. What is it decompressing anyways? I don't know much about terminal
programs, but from the other symbol names in that stack trace
(VteTerminalPrivate::insert_rows, _vte_ring_insert), I wonder if this
involves the scrollback history. Toggling lilyterm's "Scrollback lines"
option didn't seem to help.

I'll keep digging, and I'll file a bug on the gnome tracker.

cheers,
 -Brian