Bug#862591: libvte-2.91-0: xfce4-terminal crashes when dumping a lot of text
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
Bug#862591: libvte-2.91-0: xfce4-terminal crashes when dumping a lot of text
Upstream bug filed in: https://bugzilla.gnome.org/show_bug.cgi?id=782715 cheers, -Brian
Bug#862591: libvte-2.91-0: xfce4-terminal crashes when dumping a lot of text
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, _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
Bug#862591: libvte-2.91-0: xfce4-terminal crashes when dumping a lot of text
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 0x007cb52229fc in __GI_raise (sig=sig@entry=6) at > ../sysdeps/unix/sysv/linux/raise.c:51 > #1 0x007cb5223df4 in __GI_abort () at abort.c:89 > #2 0x007cb53dc59c 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, _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
Bug#862591: libvte-2.91-0: xfce4-terminal crashes when dumping a lot of text
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 Description: OpenPGP digital signature
Bug#862591: libvte-2.91-0: xfce4-terminal crashes when dumping a lot of text
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 0x007cb52229fc in __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51 #1 0x007cb5223df4 in __GI_abort () at abort.c:89 #2 0x007cb53dc59c 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 0x007cb53dc96c 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=, cmp=cmp@entry=0x7cb5fa7420 "==", arg2=arg2@entry=0, numtype=numtype@entry=105 'i') at ././glib/gtestutils.c:2488 #4 0x007cb5fa0a94 in _vte_boa_uncompress (dstlen=65512, srclen=6140, src=0x7fc82a4618 "", dst=) at ././src/vtestream-file.h:790 #5 0x007cb5fa0a94 in _vte_boa_read_with_overwrite_counter(VteBoa*, gsize, char*, _vte_overwrite_counter_t*) (boa=0x5ccf75e420 [VteBoa], offset=offset@entry=0, data=, overwrite_counter=overwrite_counter@entry=0x7fc82b4714) at ././src/vtestream-file.h:911 #6 0x007cb5fa0e54 in _vte_boa_read (data=, offset=0, boa=) at ././src/vtestream-file.h:922 #7 0x007cb5fa0e54 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 0x007cb5f79dac in _vte_ring_read_row_record (ring=0x5ccf76e568, position=, record=0x7fc82b4770) at ././src/ring.cc:124 #9 0x007cb5f79dac in _vte_ring_discard_one_row (ring=0x5ccf76e568) at ././src/ring.cc:417 #10 0x007cb5f79dac in _vte_ring_maybe_discard_one_row (ring=0x5ccf76e568) at ././src/ring.cc:439 #11 0x007cb5f79dac in _vte_ring_insert(VteRing*, gulong) (ring=ring@entry=0x5ccf76e568, position=position@entry=2761) at ././src/ring.cc:551 #12 0x007cb5f7c604 in VteTerminalPrivate::ring_insert(long, bool) (this=this@entry=0x5ccf76e490, position=2761, fill=fill@entry=false) at ././src/vte.cc:247 #13 0x007cb5f7e694 in VteTerminalPrivate::ring_append(bool) (fill=false, this=0x5ccf76e490) at ././src/vte.cc:257 #14 0x007cb5f7e694 in VteTerminalPrivate::insert_rows(unsigned int) (cnt=1, this=) at ././src/vte.cc:2188 #15 0x007cb5f7e694 in VteTerminalPrivate::update_insert_delta() (this=0x5ccf76e490) at ././src/vte.cc:2234 #16 0x007cb5f7f9e0 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 0x007cb5f8b248 in VteTerminalPrivate::process_incoming() (this=this@entry=0x5ccf76e490) at ././src/vte.cc:3686 #18 0x007cb5f8bf08 in VteTerminalPrivate::time_process_incoming() (this=this@entry=0x5ccf76e490) at ././src/vte.cc:10428 #19 0x007cb5f8bfe8 in VteTerminalPrivate::process(bool) (this=this@entry=0x5ccf76e490, emit_adj_changed=emit_adj_changed@entry=true) at ././src/vte.cc:10452 #20 0x007cb5f8c244 in update_timeout(gpointer) (data=) at ././src/vte.cc:10679 #21 0x007cb53b5484 in g_timeout_dispatch (source=0x5ccf575f80, callback=, user_data=) at ././glib/gmain.c:4674 #22 0x007cb53b4898 in g_main_dispatch (context=0x5ccf446770) at ././glib/gmain.c:3203 #23 0x007cb53b4898 in g_main_context_dispatch (context=context@entry=0x5ccf446770) at ././glib/gmain.c:3856 #24 0x007cb53b4c40 in g_main_context_iterate (context=0x5ccf446770,
