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

Closed
tagoh opened this Issue Nov 28, 2012 · 5 comments

Comments

Projects
None yet
2 participants
@tagoh
Contributor

tagoh commented Nov 28, 2012

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

This comment has been minimized.

Show comment
Hide comment
@mnogu

mnogu Nov 28, 2012

Member

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?

Member

mnogu commented Nov 28, 2012

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

This comment has been minimized.

Show comment
Hide comment
@tagoh

tagoh Nov 28, 2012

Contributor

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

Contributor

tagoh commented Nov 28, 2012

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

This comment has been minimized.

Show comment
Hide comment
@mnogu

mnogu Jan 4, 2013

Member

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.

Member

mnogu commented Jan 4, 2013

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

This comment has been minimized.

Show comment
Hide comment
@tagoh

tagoh Feb 13, 2013

Contributor

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.

Contributor

tagoh commented Feb 13, 2013

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

This comment has been minimized.

Show comment
Hide comment
@mnogu

mnogu Feb 19, 2013

Member

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

Member

mnogu commented Feb 19, 2013

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment