Finalterm crashes at keypress

[Witiko]

This is a call for the reopening of the issue #188. Following is the output I get on stderr when I run finalterm and press an arbitrary key:

** Message: TerminalOutput.vala:386: Command mode entered
Segmentation fault (core dumped)

I've analysed the core file and it appears that the program crashes during a libgdk call:

$ gdb /usr/local/bin/finalterm core | tail
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `finalterm'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x00007f6bd0222962 in gdk_window_has_impl (window=window@entry=0x0)
    at /build/buildd/gtk+3.0-3.10.8/./gdk/gdkwindow.c:596

Ltrace output:

$ ltrace finalterm 2>&1 | tail
<... gee_list_get resumed> )                     = 0x2f2b200
g_object_unref(0x2f2b200, 0x17e4398, 1, 0x1851968) = 2
g_object_unref(0x2d0fd60, 0x17e4398, 1, 0)       = 2
gtk_im_context_filter_keypress(0x30b69c0, 0x7fff94e3da70, 0x7fff94e3da70, 0 <unfinished ...>
g_free(0x35fa770, 1, 0x411510, 0x7f0c05847320)   = 0
g_free(0x3602aa0, 1, 0x411510, 0x7f0c05847320)   = 1
g_free(0x35fa7e0, 1, 0x411510, 0x7f0c05847320)   = 0
g_free(0x3602aa0, 1, 0x411510, 0x7f0c05847320)   = 0x35fa840
--- SIGSEGV (Segmentation fault) ---
+++ killed by SIGSEGV +++

Valgrind output:

$ valgrind finalterm | tail
==28008== Process terminating with default action of signal 11 (SIGSEGV)
==28008==  Access not within mapped region at address 0x90
==28008==    at 0x6429962: _gdk_window_has_impl (gdkwindow.c:583)
==28008==    by 0x645625D: gdk_x11_window_get_xid (gdkwindow-x11.c:5518)
==28008==    by 0x2CE2C3B7: gtk_im_context_xim_filter_keypress (gtkimcontextxim.c:673)
==28008==    by 0x5E6EF92: gtk_im_multicontext_filter_keypress (gtkimmulticontext.c:361)
==28008==    by 0x414AE4: final_term_on_key_press_event (FinalTerm.vala:236)
==28008==    by 0x412C0D: _final_term_on_key_press_event_gtk_widget_key_press_event (FinalTerm.c:643)
==28008==    by 0x5E89E0B: _gtk_marshal_BOOLEAN__BOXED (gtkmarshalers.c:85)
==28008==    by 0x71233B7: g_closure_invoke (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4000.0)
==28008==    by 0x7134D3C: ??? (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4000.0)
==28008==    by 0x713C6F8: g_signal_emit_valist (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4000.0)
==28008==    by 0x713CCE1: g_signal_emit (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4000.0)
==28008==    by 0x5FB2E33: gtk_widget_event_internal (gtkwidget.c:7168)
==28008==  If you believe this happened as a result of a stack
==28008==  overflow in your program's main thread (unlikely but
==28008==  possible), you can try to increase the size of the
==28008==  main thread stack using the --main-stacksize= flag.
==28008==  The main thread stack size used in this run was 8388608.
==28008== 
==28008== HEAP SUMMARY:
==28008==     in use at exit: 29,965,483 bytes in 112,131 blocks
==28008==   total heap usage: 349,504 allocs, 237,373 frees, 73,869,039 bytes allocated
==28008== 
==28008== LEAK SUMMARY:
==28008==    definitely lost: 105,780 bytes in 169 blocks
==28008==    indirectly lost: 117,650 bytes in 2,758 blocks
==28008==      possibly lost: 24,503,200 bytes in 31,917 blocks
==28008==    still reachable: 4,695,253 bytes in 74,885 blocks
==28008==         suppressed: 0 bytes in 0 blocks
==28008== Rerun with --leak-check=full to see details of leaked memory
==28008== 
==28008== For counts of detected and suppressed errors, rerun with: -v
==28008== ERROR SUMMARY: 82 errors from 4 contexts (suppressed: 0 from 0)
Killed (SIGKILL)

Uname output:

$ uname -a
Linux witiko-D830 3.11.0-20-generic #34-Ubuntu SMP Tue Apr 1 20:40:25 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux

I will gladly procure any other outputs you may find useful.

[p-e-w]

Thank you for the detailed writeup. Obviously, I still cannot reproduce the issue, but the gtk_im_context_filter_keypress makes me wonder that it might have something to do with the input method. Are you using any enhanced input method like pinyin, accessibility helpers etc.?

[p-e-w]

I just found that https://github.com/p-e-w/finalterm/issues/364 looks very similar to this issue. Can you try if the fix described there works for you?

[Witiko]

I'm not using any accessibility helpers and yes, this appears to be a duplicate of #364.

[p-e-w]

Duplicate of https://github.com/p-e-w/finalterm/issues/364.