Please do not redirect away from the mailing list. There's no guarantee that the people who have responded most recently are the ones to solve the problem, and there are very likely others on the list who can benefit from the discussion. Vladimir> (gdb) run Vladimir> Starting program: /usr/bin/xemacs Vladimir> (no debugging symbols found)... *sigh* I really wish distros would stop stripping binaries (either that, or provide toll-free help lines---stripped binaries make debugging an order of magnitude harder). Vladimir> Fatal error: assertion failed, file xlwtabs.c, line Vladimir> 1997, *reply_width > 0 && *reply_height > 0 OK, this assert _can't_ happen because *reply_width = (x > 10 ? x : 10) and similarly for reply_height. Of course it did happen, and the reason it can is that there's stack manipulation (a function return) between the assignment and the assert. So I would assume your stack has been smashed somehow, or you're running out of stack space. At the point of the crash in the debugger, try changing to the assert frame (gdb) frame 3 and then printing out the values of the asserted variables (gdb) print *reply_width (gdb) print *reply_height To make much headway, we probably need a build with debugging symbols. configure --debug ... (where ... is your usual set of options), and do not strip the binary. See if you get a crash in that case. If so, I suspect that both flyspell and mh-e use a fair amount of regexps, which are known to be hard on the stack. You could try cd'ing to the src directory and typing make 'CFLAGS=-DREGEX_MALLOC' regex.o; make which will rebuild XEmacs to use malloc instead of stack allocation for regex backtracking frames. This is known to help with some other regex-related crashes. -- Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Ask not how you can "do" free software business; ask what your business can "do for" free software.