Jan> Staring xemacs in X11 and then exiting directly with C-x Jan> C-c gives a segmentation violation: Jan, thanks for the detailed report. Can you tell us the link command used to build XEmacs, please? I'd like to know if input-method-motif.o is linked or not. You can look at src/Makefile, input-method-motif.o should appear in the variable extra_objs defined around line 29. Or if you have a make log, it'll be in there. Or you can rm src/xemacs and make again. If you have the inclination, you could also build with Glynn's patch (attached) applied to src/input-method-motif.c, and test. (If input-method-motif.o is not linked, it's a waste of time, though.) Glynn> Did the input-method-motif.c patch get applied to 21.4.0? No. I was hoping for some experience with the patch, but I guess I'm just going to take Valdis as a representative sample, apply it to 21.4.1, and pray. Glynn> This stack trace looks familiar (although there isn't any Glynn> reference to MULE in the configure command). There also is no reference to XmIm* in the stack trace. (In fact, no Xm* anything!) Your patch won't help here, I bet---input-method-motif probably is not linked into Jan's XEmacs. :-/ BTW, thanks for fielding questions on c.e.x, I want to be there but haven't found the time yet. :-/ You didn't ask for a wild-ass guess, but here it is anyway: Could XEmacs, specifically x_delete_frame(), be systematically passing something incorrect to XtDisplayOfObject, which passes it along to XtIsSubclass? Maybe because what XEmacs gets from Motif is subtly different from what it would get from plain Xt? ------------------------------------------------------------------------ Glynn's patch: Index: src/input-method-motif.c =================================================================== RCS file: /usr/CVSroot/XEmacs/xemacs/src/input-method-motif.c,v retrieving revision 1.9.2.3 diff -u -r1.9.2.3 input-method-motif.c --- src/input-method-motif.c 2000/01/26 12:34:03 1.9.2.3 +++ src/input-method-motif.c 2001/03/29 23:08:54 ＠＠ -94,6 +94,13 ＠＠ /* Nothing to do */ } +/* Callback for the deleting frame. */ +static void +XIM_delete_frame (Widget w, XtPointer client_data, XtPointer call_data) +{ + XmImUnregister ((Widget) client_data); +} + void XIM_init_frame (struct frame *f) { ＠＠ -152,6 +159,8 ＠＠ NULL); XmFontListEntryFree (&fontlistEntry); + + XtAddCallback (w, XmNdestroyCallback, XIM_delete_frame, (XtPointer) w); } void -- University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091 _________________ _________________ _________________ _________________ What are those straight lines for? "XEmacs rules."

Stephen J. Turnbull wrote: Well, without the patch, using input-method-motif.c seems to guarantee disaster (for me, and AFAICT for Valdis, deleting a frame always causes instant segfault). Yep; I suspect you're right. I'd forgotten about the explicit _XmImFreeShellData in the stack trace. Here's mine: does it go away if you don't pass "--external-widget" to configure? x_delete_frame() doesn't call XtDisplayOfObject() directly, and I can't see any obvious indirect call. I did briefly suspect the following code from x_delete_frame(): #ifdef EXTERNAL_WIDGET expect_x_error (XtDisplay (FRAME_X_SHELL_WIDGET (f))); /* for obscure reasons having (I think) to do with the internal window-to-widget hierarchy maintained by Xt, we have to call XtUnrealizeWidget() here. Xt can really suck. */ if (f->being_deleted) XtUnrealizeWidget (FRAME_X_SHELL_WIDGET (f)); XtDestroyWidget (FRAME_X_SHELL_WIDGET (f)); x_error_occurred_p (XtDisplay (FRAME_X_SHELL_WIDGET (f))); #else In the EXTERNAL_WIDGET case, it appears to be passing a Widget which it's just destroyed to XtDisplay(). However, in XFree86 4.0.3 at least, XtDisplay() doesn't call XtDisplayOfObject, just DisplayOfScreen(widget->core.screen). In the XmIm* case, the crash was happening via XtDestroyWidget() and Phase2Destroy(), whereas the stack trace suggests that x_delete_frame() is calling XtDisplayOfObject directly (although I suppose that might be an artifact of -fomit-frame-pointer; if Motif was built with this option, wouldn't that eradicate any trace of Motif from the stack trace?). -- Glynn Clements <glynn.clements(a)virgin.net&gt;