infinite loop in gtk_im_context_reset()->preedit_changed->...

[tagoh]

Originally the bug was reported at https://bugzilla.redhat.com/show_bug.cgi?id=879499

the backtrace is available here: https://bugzilla.redhat.com/attachment.cgi?id=650234

[mnogu]

I tried to reproduce this bug following the procedure described in the comment 17 in the Red Hat Bugzilla, but failed to reproduce it.

Did you use uim-anthy when you reproduced this bug?

[tagoh]

Yes. well, it's now always reproducible here but it worked initially unless I'm on crack. I don't know if there are anything information stored into the DB say that cause 'preedit_changed', even though all of relevant processes is restarted. that said, I tried to remove $HOME/.uim.d, I can still reproduce it.

Other than that I forgot to mention there is, I did test it without changing IM. i.e. I kept ibus running. plus, indeed it works without any problems if I change the input method on im-chooser say, to uim. and if I run with GTK_IM_MODULE=uim even as I mentioned there.

That may sounds relevant to ibus but that backtrace doesn't contain anything related to ibus at all.

Ah, I just realized that that backtrace isn't full. in fact the stack is more deeper than over 40000. let me quote where it was began:

(gdb) bt -110
#46650 0x00000033593333bc in gtk_im_multicontext_get_preedit_string (context=
    0xc53e40 [GtkIMMulticontext], str=0x7fffffff9238, attrs=0x0, cursor_pos=
    0x7fffffff9234) at gtkimmulticontext.c:312
#46651 0x000000335932fea2 in IA__gtk_im_context_get_preedit_string (context=
    0xc53e40 [GtkIMMulticontext], str=str@entry=0x7fffffff9238, 
    attrs=attrs@entry=0x0, cursor_pos=cursor_pos@entry=0x7fffffff9234)
    at gtkimcontext.c:447
#46652 0x00000033592c9bf5 in gtk_entry_preedit_changed_cb (entry=
    0xbdbe40 [GtkEntry], context=<optimized out>) at gtkentry.c:5176
#46653 gtk_entry_preedit_changed_cb (context=<optimized out>, entry=
    0xbdbe40 [GtkEntry]) at gtkentry.c:5168
#46654 0x0000003344a0f943 in _g_closure_invoke_va (closure=closure@entry=
    0xc67ad0, return_value=return_value@entry=0x0, instance=instance@entry=
    0xc53e40, args=args@entry=0x7fffffff9578, n_params=0, param_types=0x0)
    at gclosure.c:840
#46655 0x0000003344a27d88 in g_signal_emit_valist (instance=instance@entry=
    0xc53e40, signal_id=signal_id@entry=218, detail=detail@entry=0, 
    var_args=var_args@entry=0x7fffffff9578) at gsignal.c:3211
#46656 0x0000003344a28cd0 in g_signal_emit_by_name (instance=0xc53e40, 
    detailed_signal=0x335951b481 "preedit-changed") at gsignal.c:3393
#46657 0x0000003344a0f943 in _g_closure_invoke_va (closure=closure@entry=
    0x1315300, return_value=return_value@entry=0x0, instance=instance@entry=
    0x1333d10, args=args@entry=0x7fffffff99c8, n_params=0, param_types=0x0)
---Type <return> to continue, or q <return> to quit---
    at gclosure.c:840
#46658 0x0000003344a27d88 in g_signal_emit_valist (instance=instance@entry=
    0x1333d10, signal_id=signal_id@entry=218, detail=detail@entry=0, 
    var_args=var_args@entry=0x7fffffff99c8) at gsignal.c:3211
#46659 0x0000003344a28cd0 in g_signal_emit_by_name (instance=0x1333d10, 
    detailed_signal=detailed_signal@entry=0x7fffee1b3e21 "preedit_changed")
    at gsignal.c:3393
#46660 0x00007fffee1a95fd in update_cb (ptr=0x1333d10) at gtk-im-uim.c:671
#46661 0x00007fffee1a9642 in im_uim_reset (ic=<optimized out>)
    at gtk-im-uim.c:1474
#46662 0x0000003359332b75 in gtk_im_multicontext_set_slave (
    multicontext=multicontext@entry=0xc53e40 [GtkIMMulticontext], 
    slave=slave@entry=0x0, finalizing=finalizing@entry=0)
    at gtkimmulticontext.c:164
#46663 0x0000003359332e74 in gtk_im_multicontext_get_slave (
    multicontext=multicontext@entry=0xc53e40 [GtkIMMulticontext])
    at gtkimmulticontext.c:241
#46664 0x000000335933351a in gtk_im_multicontext_set_client_window (
    context=<optimized out>, window=0x12a8360 [GdkWindow])
    at gtkimmulticontext.c:300
#46665 0x00000033592cd8d7 in gtk_entry_realize (widget=0xbdbe40 [GtkEntry])
    at gtkentry.c:2809
#46666 0x0000003344a0f664 in g_closure_invoke (closure=closure@entry=0xada590, 
---Type <return> to continue, or q <return> to quit---
    return_value=return_value@entry=0x0, n_param_values=1, 
    param_values=param_values@entry=0x7fffffff9e40, 
    invocation_hint=invocation_hint@entry=0x7fffffff9de0) at gclosure.c:777
#46667 0x0000003344a20003 in signal_emit_unlocked_R (node=node@entry=0xada5e0, 
    detail=detail@entry=0, instance=instance@entry=0xbdbe40, 
    emission_return=emission_return@entry=0x0, 
    instance_and_params=instance_and_params@entry=0x7fffffff9e40)
    at gsignal.c:3481
#46668 0x0000003344a2866d in g_signal_emit_valist (instance=0xbdbe40, 
    signal_id=<optimized out>, detail=0, var_args=var_args@entry=
    0x7fffffffa088) at gsignal.c:3300
#46669 0x0000003344a287c2 in g_signal_emit (instance=instance@entry=0xbdbe40, 
    signal_id=<optimized out>, detail=detail@entry=0) at gsignal.c:3356
#46670 0x0000003359488cfd in IA__gtk_widget_realize (widget=
    0xbdbe40 [GtkEntry]) at gtkwidget.c:3561
#46671 0x00000033594893c8 in IA__gtk_widget_map (widget=0xbdbe40 [GtkEntry])
    at gtkwidget.c:3435
#46672 0x00000033593e4e10 in gtk_table_forall (container=<optimized out>, 
    include_internals=<optimized out>, callback=
    0x33592bda60 <gtk_container_map_child>, callback_data=0x0)
    at gtktable.c:935
#46673 0x00000033592c117f in gtk_container_map (widget=0x835650 [GtkTable])
    at gtkcontainer.c:2684
---Type <return> to continue, or q <return> to quit---q
Quit

Hope that helps

[mnogu]

I can't still reproduce this bug in my Fedora 17 env. I hope someone reproduces it and sends a pull request to fix it.

[tagoh]

Hmm, well, the issue is obvious from the above backtrace. GTK+ has considered to switch the immodule because priv->context_id and the result of get_effective_context_id() is different and calling gtk_im_context_reset() before switching it off. in im-uim.so, once uim_reset_context() is done, it's sending a signal `preedit_changed'. then the context id is required to obtain the preedit string. so it's back to the above loop of sequence.

first, calling gtk_im_context_reset() prior to switch the slave immodule off makes sense to me to nullify the working spaces. but is it really always necessary to send 'preedit_changed' signal anyway? it looks to me like uim doesn't need to send it when no preedit is started at all:

--- a/gtk2/immodule/gtk-im-uim.c
+++ b/gtk2/immodule/gtk-im-uim.c
@@ -668,7 +668,8 @@ update_cb(void *ptr)
   if (uic->prev_preedit_len == 0 && preedit_len)
     g_signal_emit_by_name(uic, "preedit_start");

-  g_signal_emit_by_name(uic, "preedit_changed");
+  if (uic->prev_preedit_len || preedit_len)
+    g_signal_emit_by_name(uic, "preedit_changed");

   if (uic->prev_preedit_len && preedit_len == 0)
     g_signal_emit_by_name(uic, "preedit_end");

Though I can't figure out about the side effects of this change, this issue is gone away at least.

[mnogu]

Thank you for the explanation and the patch. I've pushed your patch to both the 1.8 and the master branch.