Re: Argh. Why is this happening to me?
Valdis.Kletnieks(a)vt.edu wrote:
2685 XtDestroyWidget (FRAME_X_SHELL_WIDGET (f));
> Does just "--with-xim=xlib" do the trick? There have
been patches floating
> around to disable motif based xim completely because of its instability.
That produces a so-far stable XEmacs.
The odd part is that if Mule is compiled in along with Motif,
it's
a problem - even if the file being edited via gnuclient is strict
printable us-ascii. Weird...
Not that wierd. To recap from the original backtrace:
#3 0x40130375 in _XmImFreeShellData () at eval.c:41
Hmm. VendorShell defines some XIM resources, but they don't go
directly in VendorShellPart; that just contains a pointer to the
"vendor specific" data (XmVendorShellExtClassRec for Motif).
$ gdb /usr/local/bin/xemacs
[snipped]
break x_delete_frame
Breakpoint 1 at 0x82104f9: file
frame-x.c, line 2672.
run -vanilla
Starting program: /usr/local/bin/xemacs
-vanilla
Breakpoint 1, x_delete_frame (f=0x86fc7d0) at frame-x.c:2672
2672 assert (FRAME_X_SHELL_WIDGET (f) != 0);
next
2673 dpy = XtDisplay (FRAME_X_SHELL_WIDGET (f));
step
XtDestroyWidget (widget=0x8718a00) at Destroy.c:331
331 app = XtWidgetToApplicationContext(widget);
print ((TopLevelEmacsShellWidget) widget)->vendor
$4 =
{vendor_specific = 0}
print ((TopLevelEmacsShellWidgetClass)
(widget->core.widget_class))->vendor_shell_class
$5 = {extension = 0x0}
Shouldn't these be getting initialised somehow? (rhetorical question).
None of the Motif documentation which I have provides any real details
on writing Shell subclasses. It wouldn't surprise me if there's some
subtlety regarding Motif, XIM and Shell widgets that's being
overlooked.
Nothing in EmacsShell-sub.c is Motif-specific, and
input-method-motif.c is only 5Kb which seems, well, too simple.
Unfortunately the debugging hit a bit of dead end when it got into
libXm (no debug info there).
--
Glynn Clements <glynn(a)sensei.co.uk>