Re: [Bug: 21.4.17] fatal error(11) with seg fault in the middle of error report

Leena> (gdb) where Leena> #0 0x080ae04f in Frunning_temacs_p () Leena> #1 0x081d44b8 in hash_table_description () Leena> #2 0x0000000b in ?? () Leena> #3 0xbfffcecc in ?? () Leena> #4 0x08192990 in sys_do_signal () Leena> #5 0xbfffca6c in ?? () Leena> #6 0x0000000b in ?? () Leena> #7 0x00000000 in ?? () etc, etc. This stack trace makes no sense (it's not possible for a program to execute instructions at address 0x00000000, hash_table_description is a variable, not a function). Furthermore, the executable has been stripped of all debugging information; there's basically no hope for debugging. Your best bet is to upgrade to a newer version of XEmacs (21.4.19 is current). The next is to send a report to the place you got the binary (Mandriva, I guess) and hope they can debug it (since they created the package, they probably could reproduce the symbol table, or maybe they have a debug package with an unstripped XEmacs). You could also try running under gdb (something like "gdb `which xemacs`"), and trying to get a sane stack trace. However, it will still be nearly impossible to interpret, since it will have no information about argument values and so on. -- School of Systems and Information Engineering 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.