>>>> "JM" == Jeff Miller
<jmiller(a)smart.net> writes:
JM> I working on porting some lisp code from Emacs to XEmacs. One area I'm
JM> having a problem in is with a certain popup menu. It works ok on Emacs
JM> but crashes XEmacs. I think it has to do with the length of the strings
JM> being put into the popup menu.
JM> I'm been able to come up with a simple snippet of lisp code that can
JM> recreate it. It would appear the magic number to make it crash is 64
JM> characters.
more info......
The crash occurs on my optimized for speed XEmacs. I noticed that I tried
this in the one I compile with less optimization, it works as expected.
so I've been compiling various combos of configure options and cflags to
find out where it falls down. Turns out if I turn on _any_ "-O" options
in the cflags, I get the core dump. This is all the info I get from gdb
and so on.
Lisp backtrace follows:
popup-menu((""
"1234567890123456789012345678901234567890123456789012345678901234"))
# bind (menu)
(let* ((menu ...)) (popup-menu menu))
)
crash()
eval((crash))
# (condition-case ... . error)
# (catch top-level ...)
Segmentation fault (core dumped)
[jmiller@localhost xemacs-21.0-b40]$ gdb src/xemacs core
GDB is free software and you are welcome to distribute copies of it
under certain conditions; type "show copying" to see the conditions.
There is absolutely no warranty for GDB; type "show warranty" for details.
GDB 4.16 (i386-redhat-linux), Copyright 1996 Free Software Foundation, Inc...
Core was generated by `src/xemacs'.
Program terminated with signal 11, Segmentation fault.
find_solib: Can't read pathname for load map: Input/output error
#0 0x40378131 in ?? () from /lib/libc.so.6
(gdb) where
#0 0x40378131 in ?? () from /lib/libc.so.6
#1 0x80a9165 in fatal_error_signal (sig=11) at emacs.c:262
#2 0xbfffe968 in ?? ()
Cannot access memory at address 0x36353433.
(gdb)
I've been using egcs 1.0.1. and glibc 2.0.something old. whatever came
with redhat 5.0.
i'll try gcc2.7.2.x & 1.0.3 next.