Public bug reported:
On an arm64 system (Cortex-A57 based AMD Overdrive), dumping a lot of
data to a gnome-terminal window crashes the gnome-terminal-server
process.
For instance, doing something like
$ hexdump -C /dev/urandom
will crash within a matter of seconds with the following backtrace
Vte:ERROR:/build/vte2.91-uFdgfJ/vte2.91-0.44.2/./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)
Thread 1 "gnome-terminal-" received signal SIGABRT, Aborted.
0x0000ffffb724cb74 in raise () from /lib/aarch64-linux-gnu/libc.so.6
(gdb) bt
#0 0x0000ffffb724cb74 in raise () from /lib/aarch64-linux-gnu/libc.so.6
#1 0x0000ffffb724df5c in abort () from /lib/aarch64-linux-gnu/libc.so.6
#2 0x0000ffffb7419704 in g_assertion_message
(domain=domain@entry=0xffffb7fa6d40 "Vte", file=file@entry=0xffffb7faefc8
"/build/vte2.91-uFdgfJ/vte2.91-0.44.2/./src/vtestream-file.h",
line=line@entry=790,
func=func@entry=0xffffb7faee48 <_vte_boa_uncompress::__PRETTY_FUNCTION__>
"unsigned int _vte_boa_uncompress(char*, unsigned int, const char*, unsigned
int)",
message=message@entry=0x976a40 "assertion failed (z_ret == Z_OK):
(4294967293 == 0)") at ../../../../glib/gtestutils.c:2433
#3 0x0000ffffb7419ad4 in g_assertion_message_cmpnum (domain=0xffffb7fa6d40
"Vte", file=0xffffb7faefc8
"/build/vte2.91-uFdgfJ/vte2.91-0.44.2/./src/vtestream-file.h", line=790,
func=0xffffb7faee48 <_vte_boa_uncompress::__PRETTY_FUNCTION__> "unsigned
int _vte_boa_uncompress(char*, unsigned int, const char*, unsigned int)",
expr=<optimized out>, arg1=<optimized out>,
cmp=0xffffb7faa220 "==", arg2=<optimized out>, numtype=<optimized out>) at
../../../../glib/gtestutils.c:2489
#4 0x0000ffffb7fa3cdc in _vte_boa_uncompress (dstlen=65512, srclen=7197,
src=0xfffffffeeb78 "", dst=<optimized out>) at ././src/vtestream-file.h:790
#5 _vte_boa_read_with_overwrite_counter (boa=0x510c20, offset=offset@entry=0,
data=<optimized out>, overwrite_counter=overwrite_counter@entry=0xffffffffec74)
at ././src/vtestream-file.h:911
#6 0x0000ffffb7fa4094 in _vte_boa_read (data=<optimized out>, offset=0,
boa=<optimized out>) at ././src/vtestream-file.h:922
#7 _vte_file_stream_read (astream=0x54a8a0, offset=24, data=0xffffffffecb0
"\001", len=24) at ././src/vtestream-file.h:1138
#8 0x0000ffffb7f7d93c in _vte_ring_read_row_record (ring=0x7e47b8,
position=<optimized out>, record=0xffffffffecd0) at ././src/ring.cc:124
#9 _vte_ring_discard_one_row (ring=0x7e47b8) at ././src/ring.cc:417
#10 _vte_ring_maybe_discard_one_row (ring=0x7e47b8) at ././src/ring.cc:439
#11 _vte_ring_insert (ring=ring@entry=0x7e47b8, position=position@entry=10000)
at ././src/ring.cc:551
#12 0x0000ffffb7f8012c in VteTerminalPrivate::ring_insert
(this=this@entry=0x7e46e0, position=10000, fill=fill@entry=false) at
././src/vte.cc:247
#13 0x0000ffffb7f82204 in VteTerminalPrivate::ring_append (fill=false,
this=0x7e46e0) at ././src/vte.cc:257
#14 VteTerminalPrivate::insert_rows (cnt=1, this=<optimized out>) at
././src/vte.cc:2419
#15 VteTerminalPrivate::update_insert_delta (this=0x7e46e0) at
././src/vte.cc:2465
#16 0x0000ffffb7f8f324 in VteTerminalPrivate::process_incoming
(this=this@entry=0x7e46e0) at ././src/vte.cc:3808
#17 0x0000ffffb7f8ffe0 in VteTerminalPrivate::time_process_incoming
(this=this@entry=0x7e46e0) at ././src/vte.cc:10652
#18 0x0000ffffb7f900c0 in VteTerminalPrivate::process
(this=this@entry=0x7e46e0, emit_adj_changed=emit_adj_changed@entry=true) at
././src/vte.cc:10676
#19 0x0000ffffb7f903c4 in update_repeat_timeout (data=<error reading variable:
value has been optimized out>) at ././src/vte.cc:10819
#20 0x0000ffffb73f2634 in g_timeout_dispatch (source=0x9c6db0,
callback=<optimized out>, user_data=<optimized out>) at
../../../../glib/gmain.c:4674
#21 0x0000ffffb73f1a50 in g_main_dispatch (context=0x4ae300) at
../../../../glib/gmain.c:3203
#22 g_main_context_dispatch (context=context@entry=0x4ae300) at
../../../../glib/gmain.c:3856
#23 0x0000ffffb73f1df0 in g_main_context_iterate
(context=context@entry=0x4ae300, block=block@entry=1,
dispatch=dispatch@entry=1, self=<optimized out>) at
../../../../glib/gmain.c:3929
#24 0x0000ffffb73f1eb4 in g_main_context_iteration
(context=context@entry=0x4ae300, may_block=may_block@entry=1) at
../../../../glib/gmain.c:3990
#25 0x0000ffffb75b9a00 in g_application_run (application=0x6d1130, argc=0,
argv=0x0) at ../../../../gio/gapplication.c:2381
#26 0x000000000041506c in ?? ()
The crash is caused by a failed assertion, i.e., that uncompress()
returns Z_OK. I have managed to debug it a bit, and it appears that
uncompress returns Z_DATA_ERROR because the compressed input is
corrupted, and interestingly, consists of all zeroes.
Note that this is an arm64 system, which has a weakly ordered memory
model, so this could be a synchronization issue.
The exact same bug has been reported here, running on an arm64 based
Chromebook.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=862591
The reason I am reporting this against glib2.0 and not vte2.91 is that
the issue only occurs on zesty (not on yakkety), and the version of vte
between the two is identical.
** Affects: glib2.0 (Ubuntu)
Importance: Undecided
Status: New
** Tags: arm64
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1705947
Title:
crash in libvte when dealing with large amounts of data
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/glib2.0/+bug/1705947/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
