I can't reproduce this.  How new is your gtk+, libbonoboui, etc?  If
there are more than a couple weeks old, try upgrading them and see if
the problem persists.

I use ximian 200203290257 snapshot.
I suspect xim is guilty for this problem. what about it?

Is this trace of any use, Paolo?

I really don't know how to reproduce it.

Do you have the same problem with other gnome2 apps (es. EOG)?

From the trace, it seems to crash while destroying a BonoboWindow.

Could you give me some info on XIM?

The bt is not so usefull to me.

Keizi: could you please try to turn off XIM and try to reproduce it?

1. killall ami(=xim application)
2. gedit
3. quit
---> clear!

xim is guilty.

So is this a XIM bug (and hence this should be closed) or is XIM doing
the write thing and gedit behaving poorly? I know exactly zilch about
how XIM works so I can't say.

Could you please test gtk-demo and/or testtext (in gtk+)?
Do they work with XIM?

I'm trying to understand if this is a gtk+ bug or a gedit one.
Note that I know nothing about XIM.

gtk-demo->Text Widget and testtext not crash after common message:
"""
GLib-GObject-Message: finalizing base class of GtkIMContextXIM
"""
while gedit does open crash dialog.

(I ensure that I've installed latest cvs of gtk+)

Could you please test also eog?
It should use libbonoboui (like gedit).

eh, I think I tested eog and get crash. but now eog not open crash.
and also do not flush XIM finalizing message.

How would I start or use an input method to test this?

for hangul,
1. export LANG=ko_KR.eucKR (or just ko, or korean. I cannot sure which
one supported in your system)
2. ami &, then ami launched in minimized window.
3. gedit
4. <Shift>Space may change XIM status into Korean. (in fact this step
is not necessary.)
5. quit the gedit. and crash dialog pop.

I have not ami installed on my system (RedHat 7.2).

Where can I find it?

rh72 have ami package in. I think you can install it, like Owen 
succeed. :)

I installed ami and followed your instructions.  However, pressing
shift+space did not seem to do anything.

However, when I click the right mouse button on the text area and try
to change the input method, it just displays "Default" with no other
input methods.

Do you have any ideas on why this may be happening?  Am I missing an
environment variable or something?

you may need to do:
    $ gtk-query-immodules-2.0 > ~/.gtk.immodules
and
    $ cat >> ~/.gtkrc-2.0
    im_module_file "/home/Keizi/.gtk.immodules"
    ^D

or just:
    # gtk-query-immodules-2.0 > /etc/gtk-2.0/gtk.immodules

Thanks!  I just reinstalled GTK+ from source (I was using the Ximian
snapshots) and it works now.

I can duplicate the crash.  Something is smashing the stack big time
when you close the window or try to exit the application.

Ignore the smashed stack bit.

The problem happens because:

1. The GTK+ im-xim.so module gets loaded.

2. It connects to some signals of the toplevel GEdit window, and the
callbacks are of course in the dynamic module.

3. The module gets unloaded when you change input methods, but it
never disconnects from the signals.

4. So when you destroy the GEdit window, the signal invokes the
callback which no longer is in memory, and crashes.

To duplicate the bug, it is not necessary to have AMI running or
anything.  Simply do this:

1. export LANG=ko_KR.eucKR

2. run GEdit

3. Right-click on the text area.  On the context menu, switch to the
Hangul input method.  This causes the default X input method to be
unloaded and the Hangul to be loaded.

4. Close the GEdit window.  Crash.

CCing the GTK+ people.

GTK+ bug, so changing the product.

Are you going to provide a fix for gtk, Federico? If not, please
reassign to 'owner of selected component'. Thanks.

Attaching patch, tested to work.  This is the ChangeLog entry:

2002-05-16  Federico Mena Quintero  <federico@ximian.com>

	Fixes #77008.

	* modules/input/gtkimcontextxim.h (struct _GtkIMContextXIM): Added
	a status_windows field to hold all the status windows that we
	create.

	* modules/input/gtkimcontextxim.c (gtk_im_context_xim_init):
	Initialize the status_windows field.
	(status_window_get): Set the "gtk-im-xim-toplevel" data on the
	status_window so that we can identify its toplevel window later.
	Set the "gtk-im-xim-context" data on it as well so that we can
	fetch its corresponding context.  Also, add it to the list of
	status windows for this context.
	(gtk_im_context_xim_finalize): Destroy the list of status windows
	while disconnecting them from their respective toplevels' signals.
	(status_window_destroy): Remove the status window from the list in
	its context.

Created attachment 8528 [details] [review]
Patch with proposed fix

Ignore the "#include <stdio.h>" bit in the patch; it is a leftover
from debugging printf()s.

a) There are typically many input contexts for a single
   toplevle, all of which share a single status window;
   so it does need to be done when the module is unloaded.

+      g_signal_handlers_disconnect_matched (toplevel,
+
				    G_SIGNAL_MATCH_DATA,
+
				    0, 0, NULL, NULL,
+
				    status_window);
+      g_object_set_data (G_OBJECT (toplevel), 

b) Never disconnect/connect by data alone; call 
   g_signal_handlers_disconnect_by_func() however many
   times are neccessary.Disconnecting by data is 
   considered by bad idea since you really don't have
   control over whether someone else is using that
   data in most cases.

   That's why there is no g_signal_handlers_disconnect_by_data()

Created attachment 8542 [details] [review]
Updated patch.

Re-CCing gtk-bugs; new patch has been attached.

  status_window = g_object_get_data (G_OBJECT (toplevel),
"gtk-im-xim-status\-window");
  if (status_window || !create)
    return status_window->window;

!

Made that and a few other fixes, simplified a bit, reindented
and comitted.

Fri May 17 14:40:24 2002  Owen Taylor  <otaylor@redhat.com>

	* modules/input/gtkimcontextxim.c (status_window_free): 
	Patch from Federico Mena Quintero to fix problem where
	references to IMContextXIM were kept around after
	module was unloaded. (#77008)

Great!  Thanks, Owen!

*** Bug 83226 has been marked as a duplicate of this bug. ***

*** Bug 88940 has been marked as a duplicate of this bug. ***