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