Description of problem: Another annoying bug in the latest vte series - it looks like recent vte changes are pretty untested :( ... #0 _vte_terminal_ring_append (terminal=0x182c1d8, fill=0) at vte.c:306 #1 0x00007f34619d81d2 in vte_sequence_handler_cd (terminal=0x182c1d8, params=<value optimized out>) at vteseq.c:1067 #2 0x00007f34619d88e8 in vte_sequence_handler_erase_in_display (terminal=0x182c020 [TerminalScreen], params=<value optimized out>) at vteseq.c:2675 #3 0x00007f34619c98e7 in vte_terminal_process_incoming (terminal=0x182c020 [TerminalScreen]) at vte.c:3763 #4 0x00007f34619c9ff8 in time_process_incoming (terminal=0x182c020 [TerminalScreen]) at vte.c:13971 #5 0x00007f34619ca57f in process_timeout (data=<value optimized out>) at vte.c:14018 #6 0x00007f345e86793b in g_timeout_dispatch (source=0x1786130, callback=<value optimized out>, user_data=<value optimized out>) at gmain.c:3396 #7 0x00007f345e86722e in g_main_dispatch (context=<value optimized out>) at gmain.c:1960 #8 IA__g_main_context_dispatch (context=<value optimized out>) at gmain.c:2513 #9 0x00007f345e86ac18 in g_main_context_iterate (context=0x15520c0, block=<value optimized out>, dispatch=<value optimized out>, self=<value optimized out>) at gmain.c:2591 #10 0x00007f345e86b065 in IA__g_main_loop_run (loop=0x151c8b0) at gmain.c:2799 #11 0x00007f34612b25b7 in IA__gtk_main () at gtkmain.c:1204 #12 0x00000000004159a3 in SmcSetProperties () #13 0x00007f345de9fb4d in __libc_start_main (main=<value optimized out>, argc=<value optimized out>, ubp_av=<value optimized out>, init=<value optimized out>, fini=<value optimized out>, rtld_fini=<value optimized out>, stack_end=0x7fff634fb7b8) at libc-start.c:220 #14 0x00000000004122f9 in SmcSetProperties () (gdb) print terminal $1 = 0x182c1d8 (gdb) print *terminal $2 = {widget = {object = {parent_instance = {g_type_instance = {g_class = 0xbb8}, ref_count = 30, qdata = 0x1f}, flags = 25021136}, private_flags = 0, state = 0 '\000', saved_state = 0 '\000', name = 0x18a5c00 "\200\315k\001", style = 0x1a34830 [:| ], requisition = {width = 25413888, height = 0}, allocation = {x = 0, y = 0, width = 0, height = 0}, window = 0x18129a0, parent = 0x0}, adjustment = 0x0, char_width = 4294967295, char_height = 29, char_ascent = 30, char_descent = 0, row_count = 0, column_count = 0, window_title = 0x1 <Address 0x1 out of bounds>, icon_title = 0x0, pvt = 0x0} (gdb) print terminal->pvt $3 = (VteTerminalPrivate *) 0x0 Obviously this must lead to crash in: VteRing *ring = terminal->pvt->screen->row_data; Version-Release number of selected component (if applicable): vte-0.22.2-1.fc12.x86_64 How reproducible: no idea - just using gnome-terminal with some cursor keys Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Terminal should be the most stable thing.... Otherwise its time to get back to xterm :(.... Additional info:
This looks like the bug in 0.22.1 that was fixed 0.22.2. Did you not restart gnome-terminal perhaps?
Hmm - well - it might be the case - as I often use suspend2ram - and I was not rebooting during yesterdays' upgrade. It looks like 29.Sep has been installed version 22.1 - and 30.Sep version 22.2 and the crash happened just sometimes after this upgrade. Interestingly the backtrace from this version looked meaningful so I've missed the fact that there is indeed newer version. So if you are sure the bug was fixed (i.e. there is no chance NULL pointer could appear in that place) - feel free to close the bug. Otherwise I would suggest to add at least some debug check and warn message instead of crash.
#0 _vte_terminal_ring_append (terminal=0x182c1d8, fill=0) at vte.c:306 #1 0x00007f34619d81d2 in vte_sequence_handler_cd (terminal=0x182c1d8, params=<value optimized out>) at vteseq.c:1067 #2 0x00007f34619d88e8 in vte_sequence_handler_erase_in_display (terminal=0x182c020 [TerminalScreen], params=<value optimized out>) at vteseq.c:2675 The terminal argument changes in the stack trace above. That was the bug (wrong thing passed instead of terminal), and is fixed.