Re: forwarded message from Jan D.

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;