504115 - Crash in im-xim.so when File >> Quiting after using Flash text input [@ libgobject-2.0.so.0.1600.3@0x211d3 ][@ libgobject-2.0.so.0.2200.4@0x21c64 ]

Status: RESOLVED WORKSFORME

(Core :: Widget: Gtk, defect)

Description

[drichard]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1) Gecko/20090624 Firefox/3.5
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1) Gecko/20090624 Firefox/3.5

I am trying to deploy Firefox 3.5 for use here, and it's crashing right at the end of the session when you File >> Quit.  I have uploaded a trace: 

http://crash-stats.mozilla.com/report/index/0fa5cc50-04ae-4bf3-9b05-1e5b62090714?p=1

I have noticed that it seems to happen mostly after you have done a bit of surfing.  If you open Firefox and then close it immediately, it seems not to crash.  But when you begin to navigate and then Quit, it crashes.  

kbrosnan on the IRC did a quick review and relayed this information:

<kbrosnan> dave_largo: looks like a crash related to the X input methods package or possibly font related

The other thing of note is that OpenSuse 11 ships with two versions of xul:

rpm -qa | grep xul
mozilla-xulrunner181-1.8.1.13-22.1
mozilla-xulrunner190-1.8.99.5-28.1

Firefox 3.0 is running on this same server, and is not experiencing this issue.  Both 3.0 and 3.5 were downloaded from Mozilla.org


In the hopes that provides more information, I also have generated a crash with gdb:

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xb62136d0 (LWP 16868)]
IA__g_type_check_instance (type_instance=0xa4d11e40) at gtype.c:3242
3242    gtype.c: No such file or directory.
        in gtype.c
(gdb) 

Thread 1 (Thread 0xb62136d0 (LWP 16868)):
#0  IA__g_type_check_instance (type_instance=0xa4d11e40) at gtype.c:3242
#1  0xb6bdf188 in IA__g_signal_handlers_disconnect_matched (
    instance=0xa4d11e40, mask=24, signal_id=0, detail=0, closure=0x0, 
    func=0xb2fbec00, data=0xa5e4d080) at gsignal.c:1928
#2  0xb2fbf6de in set_ic_client_window (context_xim=0xa5e4d080, 
    client_window=0x0) at gtkimcontextxim.c:1643
#3  0xb2fbf781 in xim_info_display_closed (display=0xb5f63100, is_error=0, 
    info=0xb38f7300) at gtkimcontextxim.c:404
#4  0xb6bd61fc in IA__g_cclosure_marshal_VOID__BOOLEAN (closure=0xb38ac860, 
    return_value=0x0, n_param_values=2, param_values=0xbf9df388, 
    invocation_hint=0xbf9df2c4, marshal_data=0xb2fbf730) at gmarshal.c:111
#5  0xb6bc8c3b in IA__g_closure_invoke (closure=0xb38ac860, return_value=0x0, 
    n_param_values=2, param_values=0xbf9df388, invocation_hint=0xbf9df2c4)
    at gclosure.c:490
#6  0xb6bdd1c7 in signal_emit_unlocked_R (node=0xb5f4fcd0, detail=0, 
    instance=0xb5f63100, emission_return=0x0, instance_and_params=0xbf9df388)
    at gsignal.c:2440
#7  0xb6bde67e in IA__g_signal_emit_valist (instance=0xb5f63100, signal_id=2, 
    detail=0, var_args=0xbf9df5a0 "@\220��0\020գ��\235�\b\211;�")
    at gsignal.c:2199
#8  0xb6bdeae6 in IA__g_signal_emit (instance=0xb5f63100, signal_id=2,     info=0xb38f7300) at gtkimcontextxim.c:404
#4  0xb6bd61fc in IA__g_cclosure_marshal_VOID__BOOLEAN (closure=0xb38ac860, 
    return_value=0x0, n_param_values=2, param_values=0xbf9df388, 
    invocation_hint=0xbf9df2c4, marshal_data=0xb2fbf730) at gmarshal.c:111
#5  0xb6bc8c3b in IA__g_closure_invoke (closure=0xb38ac860, return_value=0x0, 
    n_param_values=2, param_values=0xbf9df388, invocation_hint=0xbf9df2c4)
    at gclosure.c:490
#6  0xb6bdd1c7 in signal_emit_unlocked_R (node=0xb5f4fcd0, detail=0, 
    instance=0xb5f63100, emission_return=0x0, instance_and_params=0xbf9df388)
    at gsignal.c:2440
#7  0xb6bde67e in IA__g_signal_emit_valist (instance=0xb5f63100, signal_id=2, 
    detail=0, var_args=0xbf9df5a0 "@\220��0\020գ��\235�\b\211;�")
    at gsignal.c:2199
#8  0xb6bdeae6 in IA__g_signal_emit (instance=0xb5f63100, signal_id=2, 
---Type <return> to continue, or q <return> to quit---
    detail=0) at gsignal.c:2243
#9  0xb6cf43b8 in IA__gdk_display_close (display=0xb5f63100)
    at gdkdisplay.c:185
#10 0xb73b8908 in ?? () from /u/firefox_beta/firefox/libxul.so
#11 0xb73ba738 in XRE_main () from /u/firefox_beta/firefox/libxul.so
#12 0x0804951a in ?? ()
#13 0xb66da5f5 in __libc_start_main () from /lib/libc.so.6
#14 0x08049381 in ?? ()



Reproducible: Sometimes

Comment 1

[Tyler Downer [He/Him]]

Is this with a clean profile?

Comment 2

[Kevin Brosnan]

http://crash-stats.mozilla.com/report/list?product=Firefox&version=Firefox%3A3.5&platform=linux&query_search=signature&query_type=contains&query=libgobject-2.0.so.0.1600&date=&range_value=2&range_unit=weeks&do_query=1&signature=libgobject-2.0.so.0.1600.3%400x211d3

Comment 3

[drichard]

@tyler: I had tested that previously, but just did it again.  I logged into a test account, with no legacy settings and let Firefox 3.5 build them all from scratch.  I surfed for a while and then did a File > Quit, and it crashed.

@all:

Crash dump, with all fresh Firefox 3.5 settings.

http://crash-stats.mozilla.com/report/index/5e4122af-47fb-4f1e-b327-1d8f92090714

Comment 4

[timeless]

reporter: so um, which XIM (x input method) are you using?

ideally a bug like this should be reported to them. note that you can ask your distro to give you symbols and sources for glib/gdk/gtk/im, and that'd enable you to debug this problem further.

Comment 5

[drichard]

timeless: I'm not that familiar with the area of your question.  The Xserver in our case is not running on the same computer that is running Firefox.  Our HP thin clients are running Debian Linux and the Xclient computer is running OpenSuse 11.  If XIE is in the Xserver, I'm not going to be able to get a debugger to properly work because the crash is happening at the the Xclient level.  It sounds like you perceive this crash is happening outside of the realm of Firefox?

Comment 6

[timeless]

https://developer.mozilla.org/en/How_to_get_a_stacktrace_for_a_bug_report#Alternative_ways_to_get_a_stacktrace

I can't explain XIM's to you or suggest how you'd figure out which one you're using. You could try checking your distro's help or googling I guess.

the XIM is running in Gecko's process, because it's the thing that's crashing in Gecko. So your remote XServer isn't interesting.

XIMs can be used for things like entering Chinese/Japanese/Korean, or in the case of Maemo for entering text by using a finger.

I usually only encounter XIMs when they misbehave, so I'm not particularly fond of them (although, that applies to just about anything that pokes Gecko, if I see it, it's because it's misbehaving/crashing).

Comment 7

[Karl Tomlinson (:karlt)]

The reporter has symbols for the necessary libraries.
I seem to recall SUSE making xim the default gtk input module.

I think it would be worth reporting this at https://bugzilla.gnome.org/, product: gtk+, component input-methods.

GtkIMContextXIM keeps a pointer client_widget to a GtkWidget, but doesn't hold a reference nor register for destroy events.  (And I don't think the app should need to call gtk_im_context_set_client_window to clear the pointer when a parent widget is destroyed.)

Comment 8

[drichard]

all: I appreciate the hand holding in learning the right etiquette for working Firefox issues.  Firefox and before that Netscape has always just worked and been stable for us.  I have about 1000 users anxious to go live when this issue is resolved.  I'll get someone from Suse involved with inside information on these lower level X issues.  Sorry, this is beyond my expertise.  I did want to note again that FF 3.0 is running on this same computer and not experiencing this issue. So something did change between the two versions.  This issue was also happening on OpenSuse 11.1 as well.  Action items are on me for now.

Comment 9

[Karl Tomlinson (:karlt)]

(In reply to comment #8)
> I'll get someone from Suse involved with inside information on
> these lower level X issues.

If Firefox is running on the clients with Debian Linux, then that is probably whom you should get involved.

> I did want to note again that FF 3.0 is running on this same computer and
> not experiencing this issue. So something did change between the two
> versions.

If FF 3.0 is built using xulrunner (as I expect it would be on Suse) then that may be due to a different memory allocator being used.  The different memory allocator (jemalloc) would release freed memory faster.

If an official Mozilla FF 3.0 build runs fine (if they run on the clients), then that would be interesting, in which case a regression range could be enlightening.

Comment 10

[Karl Tomlinson (:karlt)]

The other issue here is that there seems to be an GtkIMContextXIM being leaked. (Though it doesn't look like resolving the leak will fix all occurrences of this crash.)

Comment 11

[drichard]

FF 3.0 and FF 3.5 are both official builds.  I'm not running the versions released by Suse.   I should be able to get FF 3.5 on the thin client itself which is running Debian Woody.  We would never deploy in this manner, but it's a very interesting test.  I should have time tomorrow to try that.

The leak note is interesting, because as I mentioned earlier, it does not crash if you open FF and then immediately close it.  You have to surf a bit, and then it happens.

Comment 12

[Karl Tomlinson (:karlt)]

Ah,  I misunderstood.
So Firefox is running on OpenSuse and the Xserver is on Debian.

It looks like there is a problem in gtk's xim input module, but it sounds like something has changed in Firefox to make us hit this problem.

Crash reports indicate this is still an issue with gtk+-2.16.1.

This crash also shows up as [@ libgobject-2.0.so.0.1600.6@0x21e63 ]
[@ libgobject-2.0.so.0.1600.6@0x24153 ] and [@ libgobject-2.0.so.0.1600.6@0x2416d ].

I don't see similar crash reports from Firefox-3.0.11.

A workaround is to set GTK_IM_MODULE=gtk-im-context-simple in the environment,
but that would disable xim, which may not be desirable.

Comment 13

[drichard]

Based on the last few comments, I inferred that it was not worth my while to install FF 3.5 on the Debian thin clients.  I did put the GTK_IM_MODULE variable into the launch script, and so far I have not crashed.  I'll continue to test and report.  

The search in comment #2 revealed that other people are crashing at quit too.

I had a quick chat with Michael Meeks from Novell this morning on the IRC, and his comment to me was that en-US shouldn't even be touching XIM.  

Let me know please if anyone needs more information, dumps or logs.  I'd be happy to get this issue resolved.  If GTK_IM_MODULE provides a workaround, I would consider deploying in this manner.

Comment 14

[Karl Tomlinson (:karlt)]

(In reply to comment #13)
> his comment to me was that en-US shouldn't even be touching XIM.  

For vanilla gtk+ installs, the GTK xim module is only used for ko:ja:th:zh locales, but SUSE has a different gtk.immodules so that xim is used in all locales:

https://bugzilla.novell.com/show_bug.cgi?id=131498

Sounds like installing scim and regenerating gtk.immodules may be a better workaround than GTK_IM_MODULE.  Not sure whether the xim entry will still need to be modified.

Comment 15

[Karl Tomlinson (:karlt)]

(In reply to comment #13)
> Let me know please if anyone needs more information, dumps or logs.

What would probably be most helpful is to get a regression window, which might indicate what caused this problem to show up.  If you have a sequence of browsing that reproduces reliably, then it should be possible to narrow this down to a day using nightly builds:

http://quality.mozilla.org/documents-home/bugs-docs/bug-triaging-guidelines/finding-regression-windows

I found a similar crash report from Firefox 3.1b2 indicating that this problem existed prior to 2008-12-01.

Comment 16

[Karl Tomlinson (:karlt)]

This crash stack is also showing up as [@ libgobject-2.0.so.0.2000.1@0x22fc3 ].

Comment 17

[drichard]

Just a quick ping.  I feel confident that the GTK_IM_MODULE variable is involved with this crash.  I haven't crashed once in two weeks with it set to 'gtk-im-context-simple'.  I have put our employees (800 users) on 3.5.1 and they too are not reporting crashes with the variable set.

I am currently trying to find an exact set of web sites to visit that cause this crash so that I can assist by going back into the daily builds.

Comment 18

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

(In reply to comment #7)
> (And I don't think the app should
> need to call gtk_im_context_set_client_window to clear the pointer when a
> parent widget is destroyed.)

http://library.gnome.org/devel/gtk/unstable/GtkIMContext.html#gtk-im-context-set-client-window
gtk_im_context_set_client_window() can clear the widget when it's destroyed. The clearing isn't invalid. How do GTK native widgets do that?

Comment 19

[Karl Tomlinson (:karlt)]

GtkEntry and GtkTextView both call gtk_im_context_set_client_window() to clear the pointer on "unrealize".  I see now that Mozilla also does this on "nsWindow::Destroy", which is very similar to unrealize.

Comment 20

[Karl Tomlinson (:karlt)]

With GTK_IM_MODULE=xim in the environment, at http://www.developingwebs.net/flash/inputdyn.php, when clicking in the "Type Here" box to focus, Flash Player calls gtk_im_context_set_client_window() with a different context and window.  There is no parallel call with a NULL window, and it seems to be this call that causes

(firefox-bin:29657): GLib-GObject-WARNING **: instance with invalid (NULL) class pointer
(firefox-bin:29657): GLib-GObject-CRITICAL **: g_signal_handlers_disconnect_matched: assertion `G_TYPE_CHECK_INSTANCE (instance)' failed

which basically means that I was fortunate enough not to crash.

Same stack as comment 0.

#0  IA__g_log (log_domain=0x7f3a5f56399c "GLib-GObject", 
    log_level=G_LOG_LEVEL_WARNING, 
    format=0x7f3a5f568550 "instance with invalid (NULL) class pointer")
    at gmessages.c:525
#1  0x00007f3a5f556807 in IA__g_type_check_instance (
    type_instance=<value optimized out>) at gtype.c:3814
#2  0x00007f3a5f552dc9 in IA__g_signal_handlers_disconnect_matched (
    instance=0x7f3a5f56399c, mask=G_SIGNAL_MATCH_DATA, signal_id=1599505744, 
    detail=1594428532, closure=0x0, func=0x0, data=0x7f3a3901a900)
    at gsignal.c:2667
#3  0x00007f3a39233020 in set_ic_client_window (context_xim=0x7f3a3901a900, 
    client_window=0x0) at gtkimcontextxim.c:1641
#4  0x00007f3a392330a4 in xim_info_display_closed (display=0x7f3a5936d170, 
    is_error=<value optimized out>, info=0x7f3a39c12710)
    at gtkimcontextxim.c:402
#5  0x00007f3a5f53ee0f in IA__g_closure_invoke (closure=0x7f3a399f05b0, 
    return_value=0x0, n_param_values=2, param_values=0x7f3a2c281910, 
    invocation_hint=0x7fff6cef3e10) at gclosure.c:767
#6  0x00007f3a5f554144 in signal_emit_unlocked_R (node=0x7f3a59361150, 
    detail=0, instance=0x7f3a5936d170, emission_return=0x0, 
    instance_and_params=0x7f3a2c281910) at gsignal.c:3247
#7  0x00007f3a5f55596b in IA__g_signal_emit_valist (instance=0x7f3a5936d170, 
    signal_id=<value optimized out>, detail=0, var_args=0x7fff6cef3ff0)
    at gsignal.c:2980
#8  0x00007f3a5f555e28 in IA__g_signal_emit (instance=0x7f3a5f56399c, 
    signal_id=16, detail=1599505744) at gsignal.c:3037
#9  0x00007f3a60078d11 in IA__gdk_display_close (display=0x7f3a5936d170)
    at gdkdisplay.c:185
#10 0x00007f3a628cf323 in MOZ_gdk_display_close (display=0x7f3a5936d170)
    at /home/karl/moz/dev/toolkit/xre/nsAppRunner.cpp:2576
#11 0x00007f3a628d6e44 in XRE_main (argc=3, argv=0x7fff6cef4ae8, 
    aAppData=0x7f3a593250f0)
    at /home/karl/moz/dev/toolkit/xre/nsAppRunner.cpp:3597
#12 0x000000000040216e in main (argc=3, argv=0x7fff6cef4ae8)
    at /home/karl/moz/dev/browser/app/nsBrowserApp.cpp:158

Comment 21

[Karl Tomlinson (:karlt)]

These crash reports ceased for dev builds when out-of-process plugins were enabled by default.  The last reports are from 2010012700.

http://crash-stats.mozilla.com/report/list?product=Firefox&version=Firefox%3A3.7a2pre&version=Firefox%3A3.7a1pre&platform=linux&query_search=signature&query_type=contains&query=gobject&date=&range_value=4&range_unit=weeks&process_type=all&plugin_field=&plugin_query_type=&plugin_query=&do_query=1&signature=libgobject-2.0.so.0.2200.3%400x21c7e

http://crash-stats.mozilla.com/report/list?product=Firefox&version=Firefox%3A3.7a2pre&version=Firefox%3A3.7a1pre&platform=linux&query_search=signature&query_type=contains&query=gobject&date=&range_value=4&range_unit=weeks&process_type=all&plugin_field=&plugin_query_type=&plugin_query=&do_query=1&signature=libgobject-2.0.so.0.2200.3%400x21c64

The lack of crashes from the plugin process would be because we don't close the display in the plugin process, though there may still be a dangling pointer and leaking GtkIMContextXIM.

There are still some similar reports, perhaps from just one person's machine:
http://crash-stats.mozilla.com/report/index/95ddf684-7b2e-4bf9-af12-2d4d72100211

Reports stopped for about 10 days after out-of-process plugins, then started again.  Perhaps this user disabled out-of-process plugins.

Comment 22

[Robert Kaiser]

(In reply to Karl Tomlinson (:karlt) from comment #21)
> These crash reports ceased for dev builds when out-of-process plugins were
> enabled by default.  The last reports are from 2010012700.

Should we still care about it, then? Or does it happen again in native UI with non-OOPP Flash?

Comment 23

[Karl Tomlinson (:karlt)]

In Flash Player versions 11,0,1,152 and 11,1,102,55, I see gtk_im_context_set_client_window calls with only NULL windows.

I suspect the lack of calls with a real window is responsible for the "Gdk-WARNING **: gdkdrawable-x11.c:952 drawable is not a pixmap or window" that I now see, but this is now a safe NULL pointer, not a dangling pointer, so this bug appears to have been resolved.