[Bug 1705947] Re: crash in libvte when dealing with large amounts of data

Ard Biesheuvel ard.biesheuvel at linaro.org
Fri Jul 28 10:56:15 UTC 2017


Actually, it appears this issue is caused by a bug in libgnutls:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=867581


** Bug watch added: Debian Bug tracker #867581
   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=867581

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to glib2.0 in Ubuntu.
https://bugs.launchpad.net/bugs/1705947

Title:
  crash in libvte when dealing with large amounts of data

Status in glib2.0 package in Ubuntu:
  New

Bug description:
  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 at entry=0xffffb7fa6d40 "Vte", file=file at entry=0xffffb7faefc8 "/build/vte2.91-uFdgfJ/vte2.91-0.44.2/./src/vtestream-file.h", line=line at entry=790, 
      func=func at entry=0xffffb7faee48 <_vte_boa_uncompress::__PRETTY_FUNCTION__> "unsigned int _vte_boa_uncompress(char*, unsigned int, const char*, unsigned int)", 
      message=message at 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 at entry=0, data=<optimized out>, overwrite_counter=overwrite_counter at 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 at entry=0x7e47b8, position=position at entry=10000) at ././src/ring.cc:551
  #12 0x0000ffffb7f8012c in VteTerminalPrivate::ring_insert (this=this at entry=0x7e46e0, position=10000, fill=fill at 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 at entry=0x7e46e0) at ././src/vte.cc:3808
  #17 0x0000ffffb7f8ffe0 in VteTerminalPrivate::time_process_incoming (this=this at entry=0x7e46e0) at ././src/vte.cc:10652
  #18 0x0000ffffb7f900c0 in VteTerminalPrivate::process (this=this at entry=0x7e46e0, emit_adj_changed=emit_adj_changed at 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 at entry=0x4ae300) at ../../../../glib/gmain.c:3856
  #23 0x0000ffffb73f1df0 in g_main_context_iterate (context=context at entry=0x4ae300, block=block at entry=1, dispatch=dispatch at entry=1, self=<optimized out>) at ../../../../glib/gmain.c:3929
  #24 0x0000ffffb73f1eb4 in g_main_context_iteration (context=context at entry=0x4ae300, may_block=may_block at 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.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/glib2.0/+bug/1705947/+subscriptions



More information about the foundations-bugs mailing list