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.