My gdb doesn't understand the addresses in the generated machine code (for natural reasons), but it manages to list the stack both above and below it. Maybe you can examine the pc and the stack yourself and see if you succeed better than gdb in determining the locations where it fails?
/ Martin Stjernholm, Roxen IS
Previous text:
2003-01-09 12:53: Subject: --with-machine-code continued
Yes, and GDB doesn't understand the stack when the segfault has occured.
Hm, interesting, with --with-dmalloc I get:
| (gdb) run -m master.pike | Starting program: /home/mirar/Pike7.5-20030109-040008/orchid/pike -m master.pike | [New Thread 16384 (LWP 32334)] | /home/mirar/Pike7.5-20030109-040008/src/callback.c:41: Fatal error: | Block alloc callback not initialized. | No stack - no backtrace. | | Program received signal SIGABRT, Aborted. | [Switching to Thread 16384 (LWP 32334)] | 0x2ab73031 in kill () from /lib/libc.so.6 | (gdb) bt | #0 0x2ab73031 in kill () from /lib/libc.so.6 | #1 0x2ab72c28 in raise () from /lib/libc.so.6 | #2 0x2ab7472b in abort () from /lib/libc.so.6 | #3 0x080e72a7 in debug_fatal (fmt=0x82d53c0 "Block alloc callback not initialized.\n") | at /home/mirar/Pike7.5-20030109-040008/src/error.c:404 | Cannot access memory at address 0x7fffffff
(--with-rtldebug --with-debug --with-cdebug --without-threads --with-compiler-trace --with-dmalloc, I'll reconfigure without dmalloc now...)
/ Mirar