Closed Bug 398512 Opened 17 years ago Closed 17 years ago

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

Categories

(Core :: Widget: Gtk, defect)

x86
Linux
defect
Not set
critical

Tracking

()

RESOLVED FIXED
mozilla1.9beta1

People

(Reporter: karlt, Assigned: karlt)

References

()

Details

(Keywords: inputmethod)

Attachments

(1 file, 1 obsolete file)

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
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)
Assignee: mozbugz → nobody
Status: ASSIGNED → NEW
Component: XRE Startup → Widget: Gtk
Product: Toolkit → Core
QA Contact: xre.startup → gtk
Target Milestone: --- → mozilla1.9 M9
Flags: blocking1.9?
This is going to leak XOpenIM connections and other data, but at least it only leaks them once.
Assignee: nobody → mozbugz
Status: NEW → ASSIGNED
Attachment #283778 - Flags: superreview?(roc)
Attachment #283778 - Flags: review?(roc)
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.
Attachment #283778 - Attachment is obsolete: true
Attachment #283818 - Flags: superreview?(roc)
Attachment #283818 - Flags: review?(roc)
Attachment #283778 - Flags: superreview?(roc)
Attachment #283778 - Flags: review?(roc)
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.
Flags: blocking1.9? → blocking1.9-
Whiteboard: [wanted-1.9]
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.
Severity: normal → critical
Summary: crash on shutdown (gdk_display_close) with gtk xim module → crash on shutdown and before restart (gdk_display_close) with gtk xim module
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.
(In reply to comment #6) > almost every startup I do is crashing his way, Every time you start, you crash?
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.
OK. Nom'ing this one again. Let's see what karlt's patch does. Thanks for speaking up, guys.
Flags: blocking1.9- → blocking1.9?
(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.
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 on attachment 283818 [details] [diff] [review] disconnect handlers and prevent unloading v1.1 evil, but "don't be evil" is not our motto.
Attachment #283818 - Flags: superreview?(roc)
Attachment #283818 - Flags: superreview+
Attachment #283818 - Flags: review?(roc)
Attachment #283818 - Flags: review+
Attachment #283818 - Flags: approval1.9+
checked in: mozilla/widget/src/gtk2/nsWindow.cpp revision 1.233
Status: ASSIGNED → RESOLVED
Closed: 17 years ago
Resolution: --- → FIXED
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.
(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.
(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.
Flags: wanted1.9+
Whiteboard: [wanted-1.9]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: