Jordan Kanter writes:
While I couldn't reproduce the bug, the segfault occurred when my
highlighted the customize(emacs) menu under options--->customize--->
The bug itself is probably in XEmacs, but we can't even be sure of
that since the trace goes through X. Is your X11 modified or a
development version (I note that there are symbols and values for X
functions but not for XEmacs)?
It looks like XEmacs itself is an Ubuntu build (since it installs into
/usr). Is that right?
If you still have the core file, and can get the symbol table (rebuild
a homebrew XEmacs without stripping it, or many distros will provide a
debug package that contains the symbol table, dunno about
Ubuntu---then point gdb at the symbol table or new executable with
"symbol-file FILE"), it would be very helpful if you could get the
stack trace with debugging symbols.
Thanks for your report. I'm not sure how far we can get without debug
symbols, but we'll keep it in mind for the next time we go to cleanup
the X11 code.
I also have a couple of comments that may help you avoid some grief in
This is not good; you do not want to be mixing GNU Emacs code into
XEmacs. If you don't have Emacs installed, but didn't build that code
yourself, you might want to make sure it was all compiled with XEmacs.
This long list of shadows is not good either. You shouldn't get a
crash from using XEmacs compiled Lisp (which is possible if you use a
.elc compiled by GNU Emacs), but bugs are likely to occur unless the
shadowed and shadowing packages are identical.
In fact, that list is quite strange in itself; libraries are
apparently shadowing themselves, and the list seems to repeat two or
XEmacs-Beta mailing list