GNOME Bugzilla – Bug 754897
catting binary files causes a crash
Last modified: 2015-09-12 06:07:39 UTC
Created attachment 311166 [details] example file vte often crashes when a non-utf8 file is dumped to the terminal. (/usr/bin/vte tends to crash faster, gnome-terminal sometimes needs 2-3 'cat's.) (vte-app:3434480): Vte-CRITICAL **: int _vte_unistr_strlen(vteunistr): assertion 's < unistr_next' failed (vte-app:3434480): Vte-CRITICAL **: void _vte_unistr_append_to_string(vteunistr, GString*): assertion 's < unistr_next' failed (vte-app:3434480): Vte-CRITICAL **: int _vte_unistr_strlen(vteunistr): assertion 's < unistr_next' failed (vte-app:3434480): Vte-CRITICAL **: void _vte_unistr_append_to_string(vteunistr, GString*): assertion 's < unistr_next' failed Segmentation fault (core dumped) vte 0.41.90.r5.g2477ae1 (today's git master) gtk 3.17.8.r116.g4993b02 (same) glib 2.45.7.r37.gee6740a (same)
(gdb) bt full
+ Trace 235436
(gdb)
Can you try running vte-2.91 under valgrind to see if anything turns up? I cannot repro here, and valgrind doesn't complain about anything inside vte.
Got the log below. Though, also noticed another odd thing – /usr/bin/vte belonging to the *old* vte 0.28.2 package (not vte3) *also* crashes in the same way... And then I have bug 754887. So maybe it's something else, e.g. glib-git, or Arch's glibc 2.22? (vte-app:3451657): Vte-CRITICAL **: void _vte_unistr_append_to_string(vteunistr, GString*): assertion 's < unistr_next' failed ==3451657== Invalid read of size 4 ==3451657== at 0x4E6B7CB: _vte_unistr_strlen (vteunistr.cc:171) ==3451657== by 0x4E427AC: _vte_ring_freeze_row (ring.cc:182) ==3451657== by 0x4E427AC: _vte_ring_freeze_one_row(_VteRing*) (ring.cc:384) ==3451657== by 0x4E42DF4: _vte_ring_maybe_freeze_one_row (ring.cc:430) ==3451657== by 0x4E42DF4: _vte_ring_insert (ring.cc:567) ==3451657== by 0x4E4C19A: _vte_terminal_ring_insert (vte.cc:343) ==3451657== by 0x4E4EDC8: _vte_terminal_ring_append (vte.cc:352) ==3451657== by 0x4E4EDC8: vte_terminal_insert_rows (vte.cc:2125) ==3451657== by 0x4E4EDC8: _vte_terminal_update_insert_delta (vte.cc:2185) ==3451657== by 0x4E501B8: _vte_terminal_cursor_down (vte.cc:3015) ==3451657== by 0x4E54093: vte_terminal_process_incoming(_VteTerminal*) (vte.cc:3839) ==3451657== by 0x4E54ABE: time_process_incoming(_VteTerminal*) (vte.cc:12847) ==3451657== by 0x4E5A14E: process_timeout(void*) (vte.cc:12896) ==3451657== by 0x657FB36: ??? (in /usr/lib/libglib-2.0.so.0.4508.0) ==3451657== by 0x657EF87: g_main_context_dispatch (in /usr/lib/libglib-2.0.so.0.4508.0) ==3451657== by 0x657F357: ??? (in /usr/lib/libglib-2.0.so.0.4508.0) ==3451657== Address 0x4136d8348 is not stack'd, malloc'd or (recently) free'd ==3451657== ==3451657== ==3451657== Process terminating with default action of signal 11 (SIGSEGV): dumping core ==3451657== Access not within mapped region at address 0x4136D8348 ==3451657== at 0x4E6B7CB: _vte_unistr_strlen (vteunistr.cc:171) ==3451657== by 0x4E427AC: _vte_ring_freeze_row (ring.cc:182) ==3451657== by 0x4E427AC: _vte_ring_freeze_one_row(_VteRing*) (ring.cc:384) ==3451657== by 0x4E42DF4: _vte_ring_maybe_freeze_one_row (ring.cc:430) ==3451657== by 0x4E42DF4: _vte_ring_insert (ring.cc:567) ==3451657== by 0x4E4C19A: _vte_terminal_ring_insert (vte.cc:343) ==3451657== by 0x4E4EDC8: _vte_terminal_ring_append (vte.cc:352) ==3451657== by 0x4E4EDC8: vte_terminal_insert_rows (vte.cc:2125) ==3451657== by 0x4E4EDC8: _vte_terminal_update_insert_delta (vte.cc:2185) ==3451657== by 0x4E501B8: _vte_terminal_cursor_down (vte.cc:3015) ==3451657== by 0x4E54093: vte_terminal_process_incoming(_VteTerminal*) (vte.cc:3839) ==3451657== by 0x4E54ABE: time_process_incoming(_VteTerminal*) (vte.cc:12847) ==3451657== by 0x4E5A14E: process_timeout(void*) (vte.cc:12896) ==3451657== by 0x657FB36: ??? (in /usr/lib/libglib-2.0.so.0.4508.0) ==3451657== by 0x657EF87: g_main_context_dispatch (in /usr/lib/libglib-2.0.so.0.4508.0) ==3451657== by 0x657F357: ??? (in /usr/lib/libglib-2.0.so.0.4508.0) ==3451657== If you believe this happened as a result of a stack ==3451657== overflow in your program's main thread (unlikely but ==3451657== possible), you can try to increase the size of the ==3451657== main thread stack using the --main-stacksize= flag. ==3451657== The main thread stack size used in this run was 8388608. ==3451657== ==3451657== HEAP SUMMARY: ==3451657== in use at exit: 4,959,531 bytes in 50,385 blocks ==3451657== total heap usage: 292,073 allocs, 241,688 frees, 27,004,100 bytes allocated ==3451657== ==3451657== LEAK SUMMARY: ==3451657== definitely lost: 7,176 bytes in 15 blocks ==3451657== indirectly lost: 29,414 bytes in 1,140 blocks ==3451657== possibly lost: 73,311 bytes in 401 blocks ==3451657== still reachable: 4,667,510 bytes in 47,406 blocks ==3451657== suppressed: 0 bytes in 0 blocks ==3451657== Rerun with --leak-check=full to see details of leaked memory ==3451657== ==3451657== For counts of detected and suppressed errors, rerun with: -v ==3451657== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0) Killed (returned 137 or SIGKILL)
Hmm, yes, it seems to actually be a glib2 thing.
Bisected down to 3188b8e in glib: commit 3188b8ee791a38ac3dd7e477f30761344442f745 Author: Mikhail Zabaluev <mikhail.zabaluev@gmail.com> Date: Tue Oct 14 01:18:57 2014 +0300 Optimized branching in g_utf8_validate()
Can you isolate the sequence passed to g_utf8_validate() that's causing a crash?
Moved the discussion to bug 738504. *** This bug has been marked as a duplicate of bug 738504 ***