> 8 libgobject-2.0.so.0 g_object_run_dispose gobject/gobject.c:1226 `ibus_proxy_connection_closed_cb()` (for the "closed" DBusConnection signal) just [calls](https://github.com/ibus/ibus/blob/1.5.23/src/ibusproxy.c#L139) `ibus_proxy_destroy()` on an IBusProxy. If not `IBUS_IN_DESTRUCTION`, then `ibus_proxy_destroy()` would [tail call](https://github.com/ibus/ibus/blob/1.5.23/src/ibusproxy.c#L148) `g_object_run_dispose()` on the proxy. > 7 libibus-1.0.so.5 libibus-1.0.so.5@0x39a01 ``` % addr2line -if -e usr/lib/debug/.build-id/0b/4a4fa0dda31cdb07836c494f33c2a30737d9c7.debug 0x39a01 ibus_proxy_dispose ./src/ibusproxy.c:102 ``` https://github.com/ibus/ibus/blob/1.5.23/src/ibusproxy.c#L102 > 6 libgobject-2.0.so.0 g_signal_emit gobject/gsignal.c:3551 If not `IBUS_DESTROYED` and not `IBUS_IN_DESTRUCTION`, then `ibus_proxy_dispose()` emits "destroy" on the proxy. > 3 libgobject-2.0.so.0 g_closure_invoke gobject/gclosure.c:810 > 2 libgobject-2.0.so.0 g_signal_emit gobject/gsignal.c:3551 We are missing a frame where the "destroy" signal handler on a proxy is emitting another signal, presumably in a tail call. A likely candidate is `_ibus_context_destroy_cb()`, which handles "destroy" on a IBusInputContext (which is an IBusProxy), unrefs the IBusInputContext and nulls the pointer from the IBusIMContext, clears pre-edit state on the IBusIMContext, and finally [emits](https://github.com/ibus/ibus/blob/1.5.23/client/gtk2/ibusimcontext.c#L1781-L1782) "preedit-changed" and "preedit-end" signals on the IBusIMContext. `_ibus_context_destroy_cb()` would be consistent with the stack in [this similar stack](https://crash-stats.mozilla.org/report/index/4a97436e-5b28-472d-b047-7326c0230521), where `IMContextWrapper::OnChangeCompositionNative()` is called to handle "preedit-changed". Signal emission keeps a reference to the IBusInputContext object, but [no reference is held to the user_data]( https://developer-old.gnome.org/gobject/stable/gobject-Signals.html#signal-memory-management) IBusIMContext. > 1 libgobject-2.0.so.0 g_signal_emit_valist gobject/gsignal.c:3274 https://gitlab.gnome.org/GNOME/glib/-/blob/dde05fd4fcd1d96d1693723ae1d7f37ecd991215/gobject/gsignal.c#L3274 `g_type_check_instance()` appears to have a bad pointer to the object on which this signal is emitted. If "preedit-changed" handling resulted in the IBusIMContext being released, then nothing else keeps the IBusIMContext alive for the "preedit-changed" signal. The IBusIMContext is owned by a GtkIMMulticontext, which is [owned by](https://searchfox.org/mozilla-central/rev/471d7fc4fc999863d72de93883db0d1aadea617b/widget/gtk/IMContextWrapper.cpp#431) a `IMContextWrapper` and [released when](https://searchfox.org/mozilla-central/rev/217cc028cb388d786e564a765df90669358616ad/widget/gtk/IMContextWrapper.cpp#657) the `nsWindow` is `Destroy()`ed. It seems plausible that IMContextWrapper's handling of "preedit-changed" might result in the `nsWindow` being destroyed. IMContextWrapper [expects](https://searchfox.org/mozilla-central/rev/217cc028cb388d786e564a765df90669358616ad/widget/gtk/IMContextWrapper.cpp#2406) that [might happen](https://searchfox.org/mozilla-central/rev/217cc028cb388d786e564a765df90669358616ad/widget/gtk/IMContextWrapper.cpp#2177). I guess [key event dispatch](https://searchfox.org/mozilla-central/rev/217cc028cb388d786e564a765df90669358616ad/widget/gtk/IMContextWrapper.cpp#2338) could trigger the window close or even the parent process might spin a nested event loop for a dialog.
Bug 1824634 Comment 7 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
> 8 libgobject-2.0.so.0 g_object_run_dispose gobject/gobject.c:1226 `ibus_proxy_connection_closed_cb()` (for the "closed" DBusConnection signal) just [calls](https://github.com/ibus/ibus/blob/1.5.23/src/ibusproxy.c#L139) `ibus_proxy_destroy()` on an IBusProxy. If not `IBUS_IN_DESTRUCTION`, then `ibus_proxy_destroy()` would [tail call](https://github.com/ibus/ibus/blob/1.5.23/src/ibusproxy.c#L148) `g_object_run_dispose()` on the proxy. > 7 libibus-1.0.so.5 libibus-1.0.so.5@0x39a01 ``` % addr2line -if -e usr/lib/debug/.build-id/0b/4a4fa0dda31cdb07836c494f33c2a30737d9c7.debug 0x39a01 ibus_proxy_dispose ./src/ibusproxy.c:102 ``` https://github.com/ibus/ibus/blob/1.5.23/src/ibusproxy.c#L102 > 6 libgobject-2.0.so.0 g_signal_emit gobject/gsignal.c:3551 If not `IBUS_DESTROYED` and not `IBUS_IN_DESTRUCTION`, then `ibus_proxy_dispose()` emits "destroy" on the proxy. > 3 libgobject-2.0.so.0 g_closure_invoke gobject/gclosure.c:810 > 2 libgobject-2.0.so.0 g_signal_emit gobject/gsignal.c:3551 We are missing a frame where the "destroy" signal handler on a proxy is emitting another signal, presumably in a tail call. A likely candidate is `_ibus_context_destroy_cb()`, which handles "destroy" on a IBusInputContext (which is an IBusProxy), unrefs the IBusInputContext and nulls the pointer from the IBusIMContext, clears pre-edit state on the IBusIMContext, and finally [emits](https://github.com/ibus/ibus/blob/1.5.23/client/gtk2/ibusimcontext.c#L1781-L1782) "preedit-changed" and "preedit-end" signals on the IBusIMContext. `_ibus_context_destroy_cb()` would be consistent with the stack in [this similar stack](https://crash-stats.mozilla.org/report/index/4a97436e-5b28-472d-b047-7326c0230521), where `IMContextWrapper::OnChangeCompositionNative()` is called to handle "preedit-changed". Signal emission keeps a reference to the IBusInputContext object, but [no reference is held to the user_data]( https://developer-old.gnome.org/gobject/stable/gobject-Signals.html#signal-memory-management) IBusIMContext. > 1 libgobject-2.0.so.0 g_signal_emit_valist gobject/gsignal.c:3274 https://gitlab.gnome.org/GNOME/glib/-/blob/dde05fd4fcd1d96d1693723ae1d7f37ecd991215/gobject/gsignal.c#L3274 `g_type_check_instance()` appears to have a bad pointer to the object on which this signal is emitted. If "preedit-changed" handling resulted in the IBusIMContext being released, then nothing else keeps the IBusIMContext alive for the "preedit-end" signal. The IBusIMContext is owned by a GtkIMMulticontext, which is [owned by](https://searchfox.org/mozilla-central/rev/471d7fc4fc999863d72de93883db0d1aadea617b/widget/gtk/IMContextWrapper.cpp#431) a `IMContextWrapper` and [released when](https://searchfox.org/mozilla-central/rev/217cc028cb388d786e564a765df90669358616ad/widget/gtk/IMContextWrapper.cpp#657) the `nsWindow` is `Destroy()`ed. It seems plausible that IMContextWrapper's handling of "preedit-changed" might result in the `nsWindow` being destroyed. IMContextWrapper [expects](https://searchfox.org/mozilla-central/rev/217cc028cb388d786e564a765df90669358616ad/widget/gtk/IMContextWrapper.cpp#2406) that [might happen](https://searchfox.org/mozilla-central/rev/217cc028cb388d786e564a765df90669358616ad/widget/gtk/IMContextWrapper.cpp#2177). I guess [key event dispatch](https://searchfox.org/mozilla-central/rev/217cc028cb388d786e564a765df90669358616ad/widget/gtk/IMContextWrapper.cpp#2338) could trigger the window close or even the parent process might spin a nested event loop for a dialog.
> 8 libgobject-2.0.so.0 g_object_run_dispose gobject/gobject.c:1226 `ibus_proxy_connection_closed_cb()` (for the "closed" DBusConnection signal) just [calls](https://github.com/ibus/ibus/blob/1.5.23/src/ibusproxy.c#L139) `ibus_proxy_destroy()` on an IBusProxy. If not `IBUS_IN_DESTRUCTION`, then `ibus_proxy_destroy()` would [tail call](https://github.com/ibus/ibus/blob/1.5.23/src/ibusproxy.c#L148) `g_object_run_dispose()` on the proxy. > 7 libibus-1.0.so.5 libibus-1.0.so.5@0x39a01 ``` % addr2line -if -e usr/lib/debug/.build-id/0b/4a4fa0dda31cdb07836c494f33c2a30737d9c7.debug 0x39a01 ibus_proxy_dispose ./src/ibusproxy.c:102 ``` https://github.com/ibus/ibus/blob/1.5.23/src/ibusproxy.c#L102 > 6 libgobject-2.0.so.0 g_signal_emit gobject/gsignal.c:3551 If not `IBUS_DESTROYED` and not `IBUS_IN_DESTRUCTION`, then `ibus_proxy_dispose()` emits "destroy" on the proxy. > 3 libgobject-2.0.so.0 g_closure_invoke gobject/gclosure.c:810 > 2 libgobject-2.0.so.0 g_signal_emit gobject/gsignal.c:3551 We are missing a frame where the "destroy" signal handler on a proxy is emitting another signal, presumably in a tail call. A likely candidate is `_ibus_context_destroy_cb()`, which handles "destroy" on a IBusInputContext (which is an IBusProxy), unrefs the IBusInputContext and nulls the pointer from the IBusIMContext, clears pre-edit state on the IBusIMContext, and finally [emits](https://github.com/ibus/ibus/blob/1.5.23/client/gtk2/ibusimcontext.c#L1781-L1782) "preedit-changed" and "preedit-end" signals on the IBusIMContext. `_ibus_context_destroy_cb()` would be consistent with the stack in [this similar report](https://crash-stats.mozilla.org/report/index/4a97436e-5b28-472d-b047-7326c0230521), where `IMContextWrapper::OnChangeCompositionNative()` is called to handle "preedit-changed". Signal emission keeps a reference to the IBusInputContext object, but [no reference is held to the user_data]( https://developer-old.gnome.org/gobject/stable/gobject-Signals.html#signal-memory-management) IBusIMContext. > 1 libgobject-2.0.so.0 g_signal_emit_valist gobject/gsignal.c:3274 https://gitlab.gnome.org/GNOME/glib/-/blob/dde05fd4fcd1d96d1693723ae1d7f37ecd991215/gobject/gsignal.c#L3274 `g_type_check_instance()` appears to have a bad pointer to the object on which this signal is emitted. If "preedit-changed" handling resulted in the IBusIMContext being released, then nothing else keeps the IBusIMContext alive for the "preedit-end" signal. The IBusIMContext is owned by a GtkIMMulticontext, which is [owned by](https://searchfox.org/mozilla-central/rev/471d7fc4fc999863d72de93883db0d1aadea617b/widget/gtk/IMContextWrapper.cpp#431) a `IMContextWrapper` and [released when](https://searchfox.org/mozilla-central/rev/217cc028cb388d786e564a765df90669358616ad/widget/gtk/IMContextWrapper.cpp#657) the `nsWindow` is `Destroy()`ed. It seems plausible that IMContextWrapper's handling of "preedit-changed" might result in the `nsWindow` being destroyed. IMContextWrapper [expects](https://searchfox.org/mozilla-central/rev/217cc028cb388d786e564a765df90669358616ad/widget/gtk/IMContextWrapper.cpp#2406) that [might happen](https://searchfox.org/mozilla-central/rev/217cc028cb388d786e564a765df90669358616ad/widget/gtk/IMContextWrapper.cpp#2177). I guess [key event dispatch](https://searchfox.org/mozilla-central/rev/217cc028cb388d786e564a765df90669358616ad/widget/gtk/IMContextWrapper.cpp#2338) could trigger the window close or even the parent process might spin a nested event loop for a dialog.