GNOME Bugzilla – Bug 753025
assertion failure on rewrap
Last modified: 2021-06-10 15:04:06 UTC
From https://retrace.fedoraproject.org/faf/problems/1012712/ : 1 raise /lib64/libc.so.6 ../sysdeps/unix/sysv/linux/raise.c 55 2 abort /lib64/libc.so.6 /usr/src/debug/glibc-2.21/stdlib/abort.c 91 3 g_assertion_message /lib64/libglib-2.0.so.0 /usr/src/debug/glib-2.44.0/glib/gtestutils.c 2356 4 g_assertion_message_expr /lib64/libglib-2.0.so.0 /usr/src/debug/glib-2.44.0/glib/gtestutils.c 2372 5 _vte_frozen_row_text_offset_to_column (inlined) /lib64/libvte-2.91.so.0 /usr/src/debug/vte-0.40.0/src/ring.c 769 6 _vte_ring_rewrap /lib64/libvte-2.91.so.0 /usr/src/debug/vte-0.40.0/src/ring.c 1034 7 vte_terminal_screen_set_size /lib64/libvte-2.91.so.0 /usr/src/debug/vte-0.40.0/src/vte.c 7842 8 vte_terminal_set_size /lib64/libvte-2.91.so.0 /usr/src/debug/vte-0.40.0/src/vte.c 7971 9 _vte_terminal_queue_contents_changed (inlined) /lib64/libvte-2.91.so.0 /usr/src/debug/vte-0.40.0/src/vte.c 874 10 vte_terminal_size_allocate /lib64/libvte-2.91.so.0 /usr/src/debug/vte-0.40.0/src/vte.c 8355
Ouch. Is this the only info we know? Anything about the circumstances, reproducibility etc.? Rewrap's been going on pretty much without problems for 1.5y now. I hope it's either another manifestation of bug 748484 (but that's a pure hope, nothing more), or a disk full (reading back zero blocks is not handled correctly) rather than a bug reproducible under normal circumstances. I've absolutely no clue though. If we had "g_assert_cmpint(a, <, b)" kinds of assertions rather than "g_assert (a < b)" kinds, would we see the actual values of the variables?
(In reply to Egmont Koblinger from comment #1) > Is this the only info we know? Anything about the circumstances, > reproducibility etc.? The complete report https://retrace.fedoraproject.org/faf/reports/641552/ isn't much more informative... apparently there's no way to get the console output/xsession-errors/etc. It does tell that this only ever was reported on f22 with vte 0.40, not before... > Rewrap's been going on pretty much without problems for 1.5y now. I hope > it's either another manifestation of bug 748484 (but that's a pure hope, > nothing more), or a disk full (reading back zero blocks is not handled > correctly) rather than a bug reproducible under normal circumstances. I've > absolutely no clue though. > > If we had "g_assert_cmpint(a, <, b)" kinds of assertions rather than > "g_assert (a < b)" kinds, would we see the actual values of the variables? Yes, it would, but useless here since we don't get this output on FAF.
Actually, also here: https://retrace.fedoraproject.org/faf/problems/1037680/ which I pasted to the wrong bug. This says it's also been in 0.38.
> Yes, it would, but useless here since we don't get this output on FAF. That's what I meant. Anyway, I'll do this change one day, it won't hurt.
I did that change a while ago.
IIRC you only did for that particular assertion that crashed, I was planning to do for all assertions in vte. So let's keep it open as a reminder.
Still happening in vte291-0.42.1-1.fc23.x86_64: https://bugzilla.redhat.com/show_bug.cgi?id=1294283
Yup. We'd need to convert all assertions to "g_assert_cmpint(a, <, b)" style throughout the entire vte codebase. And split "assert (foo && bar)" into two separate assertions.
I mean that the real bug, as in comment 0, still happens, not that there are still asserts not changed to g_assert_cmp*.
Agreed. The next step should be to somehow figure out if there was a disk full (or a failed write), causing a subsequent read() to return all zeros which are misinterpreted.
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/vte/-/issues/2211.