398512 - crash on shutdown and before restart (gdk_display_close) with gtk xim module

Status: RESOLVED FIXED

(Core :: Widget: Gtk, defect)

Description

[Karl Tomlinson (:karlt)]

See the gtk bug in the url for more info.
This is really a gtk bug but we should find a workaround.

Reproduce with GTK_IM_MODULE=xim in the environment.

A stack a catch searches:

#0  0x00002aaab1714574 in ?? ()
#1  0x00002af70b651d06 in IA__g_cclosure_marshal_VOID__BOOLEAN (
    closure=0x793d60, return_value=0x0, n_param_values=2, 
    param_values=0x7fffa18867f0, invocation_hint=0x7fffa1886550, 
    marshal_data=0x0) at gmarshal.c:111
#2  0x00002af70b638dd9 in IA__g_closure_invoke (closure=0x793d60, 
    return_value=0x0, n_param_values=2, param_values=0x7fffa18867f0, 
    invocation_hint=0x7fffa1886550) at gclosure.c:490
#3  0x00002af70b650fd2 in signal_emit_unlocked_R (node=0x528500, detail=0, 
    instance=0x529000, emission_return=0x0, 
    instance_and_params=0x7fffa18867f0) at gsignal.c:2440
#4  0x00002af70b64fcf1 in IA__g_signal_emit_valist (instance=0x529000, 
    signal_id=2, detail=0, var_args=0x7fffa1886a60) at gsignal.c:2199
#5  0x00002af70b6502c5 in IA__g_signal_emit (instance=0x529000, signal_id=2, 
    detail=0) at gsignal.c:2243
#6  0x00002af70ae99819 in IA__gdk_display_close (display=0x529000)
    at gdkdisplay.c:185
#7  0x00002af70949f617 in MOZ_gdk_display_close (display=0x529000)
    at /home/karl/moz/mozilla/toolkit/xre/nsAppRunner.cpp:2383
#8  0x00002af7094a6162 in XRE_main (argc=3, argv=0x7fffa1887528, 
    aAppData=0x505de0)
    at /home/karl/moz/mozilla/toolkit/xre/nsAppRunner.cpp:3253
#9  0x0000000000401249 in main (argc=3, argv=0x7fffa1887528)
    at /home/karl/moz/mozilla/browser/app/nsBrowserApp.cpp:153

Comment 1

[Karl Tomlinson (:karlt)]

The xim module is loaded (and causes this problem) even without GTK_IM_MODULE=xim in the environment if the locale is one of ko:ja:th:zh.
A workaround is to set GTK_IM_MODULE=gtk-im-context-simple in the environment, but that may not be so good for those locales - scim may be better.

Adding a ref to the GtkIMContextXIM Gtype prevents the xim module from being unloaded and so the display closed signal callback is valid at display close, but then the callback crashes when it does an XFree on a pointer that did not come from Xmalloc.  (http://bugzilla.gnome.org/show_bug.cgi?id=483223#c4)

Comment 2

[Karl Tomlinson (:karlt)]

Attachment: disconnect gtk xim module display closed signal handlers and prevent the module from unloading

This is going to leak XOpenIM connections and other data, but at least it only leaks them once.

Comment 3

[Karl Tomlinson (:karlt)]

Attachment: disconnect handlers and prevent unloading v1.1

Added a safety check so that we don't accidentally remove all display closed handlers with no data.  signal_data is unlikely to be NULL but might be if the window in gtk_im_context_set_client_window is NULL for some reason.

Comment 4

[Damon Sicore (:damons)]

Marking as wanted-1.9 and minusing.  Wouldn't block the beta on a shutdown crash for this.  Wouldn't block the final release on this either.

Comment 5

[Karl Tomlinson (:karlt)]

This crash also happens when we shutdown to restart after a version update, or profile creation, etc.  So a user who upgrades their firefox version must try to start firefox twice.

Comment 6

[Robert Kaiser]

almost every startup I do is crashing his way, I don't think we can so easily make this blocking- as this would be a major pain for most Linux users, making Firefox almost unusable for them.

Comment 7

[Damon Sicore (:damons)]

(In reply to comment #6)
> almost every startup I do is crashing his way, 

Every time you start, you crash? 

Comment 8

[Robert Kaiser]

I haven't found out yet in which cases exactly I crash, but the only case I really know that I reliably never crash at startup is when I manually launch Minefield, SeaMonkey trunk etc. from a console window via commandline. When launching from I desktop icon or the KDE menu, I almost always crash with trunk.

Comment 9

[Damon Sicore (:damons)]

OK.  Nom'ing this one again.  Let's see what karlt's patch does.  Thanks for speaking up, guys.

Comment 10

[Karl Tomlinson (:karlt)]

(Thanks, Damon.)

/etc/gtk-2.0/gtk.immodules on OpenSUSE 10.3 enables xim for langs matching "*" (probably almost all, not just ko:ja:th:zh), so more people will be affected than I first expected.

Comment 11

[Ben Turner (not reading bugmail, use the needinfo flag!)]

Our linux 32/64 buildbots have been red for more than a week due to this bug somehow. Thanks to Karlt's patch our bots are green today. Thanks!

Comment 12

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Comment on attachment 283818 [details] [diff] [review]
disconnect handlers and prevent unloading v1.1

evil, but "don't be evil" is not our motto.

Comment 13

[Karl Tomlinson (:karlt)]

checked in: mozilla/widget/src/gtk2/nsWindow.cpp revision 1.233

Comment 14

[Ginn Chen]

FWIW: It's still crashing on OpenSolaris.
GTK_IM_MODULES=iiim
gtk version is 2.12.0

Setting GTK_IM_MODULES to empty or xim can avoid the crash.
But there're a lot of critical warnings on shutdown.

Comment 15

[Karl Tomlinson (:karlt)]

(In reply to comment #14)
> FWIW: It's still crashing on OpenSolaris.
> GTK_IM_MODULES=iiim
> gtk version is 2.12.0

Looks like iiim is derived from xim and so has the same bug as the xim module (http://bugzilla.gnome.org/show_bug.cgi?id=483223).

I suggest filing a bug at 

http://www.openi18n.org/modules.php?op=modload&name=Sections&file=index&req=viewarticle&artid=30&page=1

linking to the gtk+ bug.  The test case in the gtk+ bug can be easily modified by changing the putenv argument.

How widely used is the iiim module?  If it is widely used then its worth filing another mozilla bug too (linking to the iiim bug).

iiim looks like it doesn't have the XFree problem so a work-around would just require preventing the module from unloading.  However, we have no way (afaict) to determine the version of the iiim module so we don't know when the workaround would be required.

> Setting GTK_IM_MODULES to empty or xim can avoid the crash.
> But there're a lot of critical warnings on shutdown.

If these are the warnings mentioned here:

  http://bugzilla.gnome.org/show_bug.cgi?id=482841

then they have been fixed ready for gtk+2.12.1.

Comment 16

[Ginn Chen]

(In reply to comment #15)
Thanks for your information!

> How widely used is the iiim module?  If it is widely used then its worth filing
> another mozilla bug too (linking to the iiim bug).
> 
It's default IM module on Solaris.

> iiim looks like it doesn't have the XFree problem so a work-around would just
> require preventing the module from unloading.  However, we have no way (afaict)
> to determine the version of the iiim module so we don't know when the
> workaround would be required.
> 

Hmm. Maybe we can keep the workaround.

> > Setting GTK_IM_MODULES to empty or xim can avoid the crash.
> > But there're a lot of critical warnings on shutdown.
> 
> If these are the warnings mentioned here:
> 
>   http://bugzilla.gnome.org/show_bug.cgi?id=482841
> 
> then they have been fixed ready for gtk+2.12.1.
> 
Yes.