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

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Brian Warner <warner@lothar.com>

To: Debian Bug Tracking System <submit@bugs.debian.org>

Subject: libvte-2.91-0: xfce4-terminal crashes when dumping a lot of text

Date: Sun, 14 May 2017 13:57:32 -0700

Package: libvte-2.91-0
Version: 0.46.1-1
Severity: grave

There seems to be a bug in sid's libvte, such that dumping a large
amount of text to stdout in a short period of time causes the terminal
program to crash. "cat" of a file with 1MB of the letter "a" is
sufficient to reproduce it.

I'm assigning this to libvte because I was able to crash xfce4-terminal,
lilyterm, and termit this way, so it's clearly not specific to any one
terminal program. I'm marking it "grave" because losing a terminal is
pretty harsh.. any programs you've spawned from there (emacs, web
browsers) abruptly exit too.

I'm running this on an ARM64 chromebook (an Acer R13), which might be an
unusual platform, just in case that makes a difference.

I was able to get a stack trace by building vte2.91-0.46.1 and
xfce4-terminal-0.8.4 locally with debug symbols turned on. It looks like
this:

Thread 1 "xfce4-terminal" received signal SIGABRT, Aborted.
__GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
51	../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
#0  0x0000007cb52229fc in __GI_raise (sig=sig@entry=6) at
../sysdeps/unix/sysv/linux/raise.c:51
#1  0x0000007cb5223df4 in __GI_abort () at abort.c:89
#2  0x0000007cb53dc59c in g_assertion_message
(domain=domain@entry=0x7cb5fa3bb8 "Vte", file=file@entry=0x7cb5fac250
"/home/warner/stuff/debian/vte2.91-0.46.1/./src/vtestream-file.h",
line=line@entry=790, func=func@entry=0x7cb5fac098
<_vte_boa_uncompress::__PRETTY_FUNCTION__> "unsigned int
_vte_boa_uncompress(char*, unsigned int, const char*, unsigned int)",
message=message@entry=0x5ccf97f720 "assertion failed (z_ret == Z_OK):
(4294967293 == 0)") at ././glib/gtestutils.c:2432
#3  0x0000007cb53dc96c in g_assertion_message_cmpnum
(domain=domain@entry=0x7cb5fa3bb8 "Vte", file=file@entry=0x7cb5fac250
"/home/warner/stuff/debian/vte2.91-0.46.1/./src/vtestream-file.h",
line=line@entry=790, func=func@entry=0x7cb5fac098
<_vte_boa_uncompress::__PRETTY_FUNCTION__> "unsigned int
_vte_boa_uncompress(char*, unsigned int, const char*, unsigned int)",
expr=expr@entry=0x7cb5fac3f8 "z_ret == Z_OK", arg1=<optimized out>,
cmp=cmp@entry=0x7cb5fa7420 "==", arg2=arg2@entry=0,
numtype=numtype@entry=105 'i')
    at ././glib/gtestutils.c:2488
#4  0x0000007cb5fa0a94 in _vte_boa_uncompress (dstlen=65512,
srclen=6140, src=0x7fc82a4618 "", dst=<optimized out>) at
././src/vtestream-file.h:790
#5  0x0000007cb5fa0a94 in _vte_boa_read_with_overwrite_counter(VteBoa*,
gsize, char*, _vte_overwrite_counter_t*) (boa=0x5ccf75e420 [VteBoa],
offset=offset@entry=0, data=<optimized out>,
overwrite_counter=overwrite_counter@entry=0x7fc82b4714) at
././src/vtestream-file.h:911
#6  0x0000007cb5fa0e54 in _vte_boa_read (data=<optimized out>, offset=0,
boa=<optimized out>) at ././src/vtestream-file.h:922
#7  0x0000007cb5fa0e54 in _vte_file_stream_read(VteStream*, gsize,
char*, gsize) (astream=0x5ccf76dc50 [VteFileStream], offset=42288,
data=0x7fc82b4750 "", len=24)
    at ././src/vtestream-file.h:1137
#8  0x0000007cb5f79dac in _vte_ring_read_row_record (ring=0x5ccf76e568,
position=<optimized out>, record=0x7fc82b4770) at ././src/ring.cc:124
#9  0x0000007cb5f79dac in _vte_ring_discard_one_row (ring=0x5ccf76e568)
at ././src/ring.cc:417
#10 0x0000007cb5f79dac in _vte_ring_maybe_discard_one_row
(ring=0x5ccf76e568) at ././src/ring.cc:439
#11 0x0000007cb5f79dac in _vte_ring_insert(VteRing*, gulong)
(ring=ring@entry=0x5ccf76e568, position=position@entry=2761) at
././src/ring.cc:551
#12 0x0000007cb5f7c604 in VteTerminalPrivate::ring_insert(long, bool)
(this=this@entry=0x5ccf76e490, position=2761, fill=fill@entry=false) at
././src/vte.cc:247
#13 0x0000007cb5f7e694 in VteTerminalPrivate::ring_append(bool)
(fill=false, this=0x5ccf76e490) at ././src/vte.cc:257
#14 0x0000007cb5f7e694 in VteTerminalPrivate::insert_rows(unsigned int)
(cnt=1, this=<optimized out>) at ././src/vte.cc:2188
#15 0x0000007cb5f7e694 in VteTerminalPrivate::update_insert_delta()
(this=0x5ccf76e490) at ././src/vte.cc:2234
#16 0x0000007cb5f7f9e0 in VteTerminalPrivate::insert_char(unsigned int,
bool, bool) (this=this@entry=0x5ccf76e490, c=97,
insert=insert@entry=false, invalidate_now=invalidate_now@entry=false) at
././src/vte.cc:2964
#17 0x0000007cb5f8b248 in VteTerminalPrivate::process_incoming()
(this=this@entry=0x5ccf76e490) at ././src/vte.cc:3686
#18 0x0000007cb5f8bf08 in VteTerminalPrivate::time_process_incoming()
(this=this@entry=0x5ccf76e490) at ././src/vte.cc:10428
#19 0x0000007cb5f8bfe8 in VteTerminalPrivate::process(bool)
(this=this@entry=0x5ccf76e490,
emit_adj_changed=emit_adj_changed@entry=true) at ././src/vte.cc:10452
#20 0x0000007cb5f8c244 in update_timeout(gpointer) (data=<error reading
variable: value has been optimized out>) at ././src/vte.cc:10679
#21 0x0000007cb53b5484 in g_timeout_dispatch (source=0x5ccf575f80,
callback=<optimized out>, user_data=<optimized out>) at
././glib/gmain.c:4674
#22 0x0000007cb53b4898 in g_main_dispatch (context=0x5ccf446770) at
././glib/gmain.c:3203
#23 0x0000007cb53b4898 in g_main_context_dispatch
(context=context@entry=0x5ccf446770) at ././glib/gmain.c:3856
#24 0x0000007cb53b4c40 in g_main_context_iterate (context=0x5ccf446770,
block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at
././glib/gmain.c:3929
#25 0x0000007cb53b4ff0 in g_main_loop_run (loop=0x5ccf441450) at
././glib/gmain.c:4125
#26 0x0000007cb5b30934 in gtk_main () at
/usr/lib/aarch64-linux-gnu/libgtk-3.so.0
#27 0x0000005ccef2d5b0 in main (argc=<optimized out>, argv=<optimized
out>) at main.c:330

I can probably get you a coredump, if that helps.

thanks!
 -Brian


-- System Information:
Debian Release: 9.0
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: arm64
 (aarch64)

Kernel: Linux 3.18.0-13759-g98e7e0e (SMP w/4 CPU cores; PREEMPT)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash
Init: unable to detect

Versions of packages libvte-2.91-0 depends on:
ii  libatk1.0-0          2.22.0-1
ii  libc6                2.24-10
ii  libcairo2            1.14.8-1
ii  libgcc1              1:6.3.0-17
ii  libglib2.0-0         2.50.3-2
ii  libgnutls30          3.5.8-5
ii  libgtk-3-0           3.22.12-1
ii  libpango-1.0-0       1.40.5-1
ii  libpangocairo-1.0-0  1.40.5-1
ii  libpcre2-8-0         10.22-3
ii  libstdc++6           6.3.0-17
ii  libvte-2.91-common   0.46.1-1
ii  zlib1g               1:1.2.8.dfsg-5

libvte-2.91-0 recommends no packages.

libvte-2.91-0 suggests no packages.

-- no debconf information

Message #10 received at 862591@bugs.debian.org (full text, mbox, reply):

From: Michael Biebl <biebl@debian.org>

To: Brian Warner <warner@lothar.com>, 862591@bugs.debian.org

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

Date: Sun, 14 May 2017 23:45:00 +0200

[Message part 1 (text/plain, inline)]

Control: tags -1 moreinfo unreproducible
Control: severity -1 normal

Am 14.05.2017 um 22:57 schrieb Brian Warner:
> Package: libvte-2.91-0
> Version: 0.46.1-1
> Severity: grave
> 
> There seems to be a bug in sid's libvte, such that dumping a large
> amount of text to stdout in a short period of time causes the terminal
> program to crash. "cat" of a file with 1MB of the letter "a" is
> sufficient to reproduce it.

I just created a test file the size of 1GB. gnome-terminal and
xfce4-terminal handled that without a hitch.
So, given that this problem seems to be not generally reproducible, I'm
downgrading the severity accordingly. (up-to-date debian sid, amd64)


If you can reliably reproduce the problem, it would be great if you can
file an upstream bug report at
https://bugzilla.gnome.org/enter_bug.cgi?product=vte

A backtrace would certainly be helpful for upstream to further diagnose
this.

Regards,
Michael

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?

[signature.asc (application/pgp-signature, attachment)]

Message #19 received at 862591@bugs.debian.org (full text, mbox, reply):

From: Andreas Henriksson <andreas@fatal.se>

To: Brian Warner <warner@lothar.com>

Cc: 862591@bugs.debian.org

Subject: Re: libvte-2.91-0: xfce4-terminal crashes when dumping a lot of text

Date: Mon, 15 May 2017 16:33:57 +0200

Hello Brian Warner,

Thanks for your bug report. Would like to add a few notes besides
what Michael already said... See below.

On Sun, May 14, 2017 at 01:57:32PM -0700, Brian Warner wrote:
> Package: libvte-2.91-0
> Version: 0.46.1-1
> Severity: grave
> 
> There seems to be a bug in sid's libvte, such that dumping a large
> amount of text to stdout in a short period of time causes the terminal
> program to crash. "cat" of a file with 1MB of the letter "a" is
> sufficient to reproduce it.

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

> 
> I'm assigning this to libvte because I was able to crash xfce4-terminal,
> lilyterm, and termit this way, so it's clearly not specific to any one
> terminal program. I'm marking it "grave" because losing a terminal is
> pretty harsh.. any programs you've spawned from there (emacs, web
> browsers) abruptly exit too.
> 
> I'm running this on an ARM64 chromebook (an Acer R13), which might be an
> unusual platform, just in case that makes a difference.
> 
> I was able to get a stack trace by building vte2.91-0.46.1 and
> xfce4-terminal-0.8.4 locally with debug symbols turned on. It looks like
> this:
> 
> Thread 1 "xfce4-terminal" received signal SIGABRT, Aborted.
> __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
> 51	../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
> #0  0x0000007cb52229fc in __GI_raise (sig=sig@entry=6) at
> ../sysdeps/unix/sysv/linux/raise.c:51
> #1  0x0000007cb5223df4 in __GI_abort () at abort.c:89
> #2  0x0000007cb53dc59c in g_assertion_message
> (domain=domain@entry=0x7cb5fa3bb8 "Vte", file=file@entry=0x7cb5fac250
> "/home/warner/stuff/debian/vte2.91-0.46.1/./src/vtestream-file.h",
> line=line@entry=790, func=func@entry=0x7cb5fac098
> <_vte_boa_uncompress::__PRETTY_FUNCTION__> "unsigned int
> _vte_boa_uncompress(char*, unsigned int, const char*, unsigned int)",
> message=message@entry=0x5ccf97f720 "assertion failed (z_ret == Z_OK):
> (4294967293 == 0)") at ././glib/gtestutils.c:2432
[...]

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.

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.)

HTH.

Regards,
Andreas Henriksson

Message #24 received at 862591@bugs.debian.org (full text, mbox, reply):

From: Brian Warner <warner@lothar.com>

To: Andreas Henriksson <andreas@fatal.se>

Cc: 862591@bugs.debian.org

Subject: Re: libvte-2.91-0: xfce4-terminal crashes when dumping a lot of text

Date: Tue, 16 May 2017 17:06:59 -0700

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

Message #29 received at 862591@bugs.debian.org (full text, mbox, reply):

From: Brian Warner <warner@lothar.com>

To: 862591@bugs.debian.org

Subject: Re: libvte-2.91-0: xfce4-terminal crashes when dumping a lot of text

Date: Tue, 16 May 2017 18:03:06 -0700

Upstream bug filed in:

https://bugzilla.gnome.org/show_bug.cgi?id=782715

cheers,
 -Brian

Message #34 received at 862591-done@bugs.debian.org (full text, mbox, reply):

From: Andreas Henriksson <andreas@fatal.se>

To: Brian Warner <warner@lothar.com>

Cc: 862591-done@bugs.debian.org

Subject: Re: libvte-2.91-0: xfce4-terminal crashes when dumping a lot of text

Date: Wed, 17 May 2017 09:24:40 +0200

Hello Brian Warner,

On Tue, May 16, 2017 at 05:06:59PM -0700, Brian Warner wrote:
[...]
> 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)
[...]

Thus z_ret = 4294967293 = -1 = Z_ERRNO

Snippet from zlib.h:

   If an error occurred
   in the file system and not in the compression library, errnum is set to
   Z_ERRNO and the application may consult errno to get the exact error code.

This means it's very likely a problem with your (non-Debian) operating
system setup. Please do not report issues to Debian when you're not
using a Debian installation (e.g. non-Debian kernel) without first making
sure it's actually reproducile on a Debian installation (or atleast
certainly not with severity grave!).
Wasting our limited time chasing non-Debian issues isn't very nice.

Regards,
Andreas Henriksson

Message #39 received at 862591@bugs.debian.org (full text, mbox, reply):

From: Brian Warner <warner@lothar.com>

To: Andreas Henriksson <andreas@fatal.se>

Cc: 862591@bugs.debian.org

Subject: Re: libvte-2.91-0: xfce4-terminal crashes when dumping a lot of text

Date: Wed, 17 May 2017 00:31:19 -0700

On 5/17/17 12:24 AM, Andreas Henriksson wrote:

> Thus z_ret = 4294967293 = -1 = Z_ERRNO
> 
> Snippet from zlib.h:
> 
>    If an error occurred in the file system and not in the compression
>    library, errnum is set to Z_ERRNO and the application may consult
>    errno to get the exact error code.
> 
> This means it's very likely a problem with your (non-Debian) operating
> system setup. Please do not report issues to Debian when you're not
> using a Debian installation (e.g. non-Debian kernel) without first
> making sure it's actually reproducile on a Debian installation (or
> atleast certainly not with severity grave!). Wasting our limited time
> chasing non-Debian issues isn't very nice.

I'm sorry about that.. I did not consider that it could be related to
the kernel. I'll investigate further and if I find any issues that are
relevant to debian, I'll add more information to this ticket.

thanks,
 -Brian

Send a report that this bug log contains spam.