Thank you for your report.
Janzen, Martin writes:
#0 0x0000002a96a9c879 in kill () from /lib64/tls/libc.so.6
(gdb) bt
#0 0x0000002a96a9c879 in kill () from /lib64/tls/libc.so.6
#1 0x0000000000489ad2 in fatal_error_signal (sig=...) at emacs.c:3853
#2 <signal handler called>
#3 0x0000002a956bcaf0 in XawVendorStructureNotifyHandler () from
/usr/X11R6/lib64/libXaw.so.7
#4 0x0000002a95f08362 in XtDispatchEventToWidget () from /usr/X11R6/lib64/libXt.so.6
#5 0x0000002a95f08673 in ?? () from /usr/X11R6/lib64/libXt.so.6
#6 0x0000002a95f08998 in XtDispatchEvent () from /usr/X11R6/lib64/libXt.so.6
This is unfortunately useless as is, because it's deep inside of X11,
and doesn't look like anything I've seen before. My suspicion is that
this is just the long-standing practice in X11 of not checking that
data received satisfies undocumented restrictions. There's possibly
something XEmacs can do to prevent this crash, but without more
information about what X was doing at the time, we can't help. (Also,
note that it's a "Vendor" handler; it could be that there's a defect
in the handler that the vendor supplied, and nothing to do with
XEmacs.)
If you still have the core file and can get the debug symbols for
libXt and libXaw, I'd really like to see the above traceback with
arguments. If you'd like to help, but don't know how, it looks like
you're using Red Hat, so maybe one of our Fedora users can help.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta