I wrote:
Here's the C backtrace:
(gdb) bt
#0 0x00000033ac92fbe7 in ?? () from /lib64/libc.so.6
#1 0x00000000004c2f65 in fatal_error_signal (sig=6)
at /home/james/Projects/xemacs/xemacs-21.5/src/emacs.c:3792
#2 <signal handler called>
#3 0x00000033ac92fbe7 in ?? () from /lib64/libc.so.6
#4 0x00000000004c2f80 in fatal_error_signal (sig=11)
at /home/james/Projects/xemacs/xemacs-21.5/src/emacs.c:3790
#5 <signal handler called>
#6 lispdesc_indirect_count_1 (code=-2, idesc=Variable "idesc" is not
available.)
at /home/james/Projects/xemacs/xemacs-21.5/src/gc.c:373
#7 0x000000000056320c in kkcc_marking (cnt=100000)
at /home/james/Projects/xemacs/xemacs-21.5/src/lrecord.h:1917
#8 0x00000000005632dc in gc_resume_mark (incremental=Variable "incremental" is
not available.
)
at /home/james/Projects/xemacs/xemacs-21.5/src/gc.c:1878
#9 0x00000000005635e0 in gc_1 (incremental=1)
at /home/james/Projects/xemacs/xemacs-21.5/src/gc.c:1913
#10 0x00000000005636b0 in gc (incremental=1)
at /home/james/Projects/xemacs/xemacs-21.5/src/gc.c:1945
#11 0x00000000004d0365 in Ffuncall (nargs=2, args=0x7fffffd0cf00)
at /home/james/Projects/xemacs/xemacs-21.5/src/eval.c:3822
#12 0x00000000004d0f87 in call1 (fn=Variable "fn" is not available.
)
at /home/james/Projects/xemacs/xemacs-21.5/src/eval.c:4545
#13 0x00000000004e1db0 in execute_internal_event (event=84134392)
at /home/james/Projects/xemacs/xemacs-21.5/src/event-stream.c:3102
#14 0x00000000004e8ff2 in Fdispatch_event (event=84134392)
at /home/james/Projects/xemacs/xemacs-21.5/src/event-stream.c:4644
#15 0x00000000004850d9 in Fcommand_loop_1 ()
at /home/james/Projects/xemacs/xemacs-21.5/src/cmdloop.c:600
#16 0x00000000004851ce in command_loop_1 (unused_dummy=Variable "unused_dummy"
is not available.
)
at /home/james/Projects/xemacs/xemacs-21.5/src/cmdloop.c:505
#17 0x00000000004cb7bf in condition_case_1 (handlers=Variable "handlers" is not
available.
)
at /home/james/Projects/xemacs/xemacs-21.5/src/eval.c:1924
#18 0x0000000000485305 in command_loop_2 (unused_dummy=Variable "unused_dummy"
is not available.
)
at /home/james/Projects/xemacs/xemacs-21.5/src/cmdloop.c:262
#19 0x00000000004c9db0 in internal_catch (tag=Variable "tag" is not available.
)
at /home/james/Projects/xemacs/xemacs-21.5/src/eval.c:1530
#20 0x0000000000485544 in initial_command_loop (load_me=Variable "load_me" is
not available.
)
at /home/james/Projects/xemacs/xemacs-21.5/src/cmdloop.c:313
#21 0x00000000004c3e77 in xemacs_21_5_b26_x86_64_unknown_linux (argc=1,
argv=0x7fffffd0d5d8, unused_envp=Variable "unused_envp" is not available.
)
at /home/james/Projects/xemacs/xemacs-21.5/src/emacs.c:2666
#22 0x00000000004c4af7 in main (argc=Variable "argc" is not available.
)
at /home/james/Projects/xemacs/xemacs-21.5/src/emacs.c:3110
Contrary to the print statement above, the crash is not due to address
0x8019c. It is due to address 0x10008019c (the value of irdata), which
is 32 bytes past 0x10008017c (the value of the idata parameter in frame
6). This is because the print statement in vdb-posix.c that prints the
addresses prints them as integers. On my platform, integers are 32 bits
and addresses are 64 bits, so the print statement chops off the upper 32
bits.
Note that the idata parameter in frame 6 is already bad: that address is
not accessible in GDB.
GDB and GCC don't seem to like each other very much on this platform
(Fedora Core 5 for x86_64); note all the "is not available" messages in
that backtrace. I can't visit anything meaningful in stack frame 7. I
even compiled with -g3 this time, because I had the same thing happen to
me when compiling with -g, but it does not seem to have helped at all.
A quick test with -O0 -g3 shows that the problem persists even then.
I'll save the core file in case someone can tell me what to do with it.
I've been able to tease GDB into giving me a little more information.
Stack frame 6, the call to lispdesc_indirect_count_1 with the bad
pointer, comes from the central for loop in kkcc_marking(). It is
crashing on the first iteration of the loop, where
desc[0] = {type = XD_BLOCK_PTR,
offset = 8,
data1 = -2,
data2 = {write_only = 0x762dd0, descr = 0x762dd0, funcs = 0x762dd0},
flags = 0}
The bad data pointer comes from kkcc_gc_stack_ptr[6732], which is:
{data = 0x10008017c, desc = 0x762d20, level = 2730, pos = 2}
As mentioned in the intial report, address 0x10008017c is an invalid
address. The information in data2 above (assuming it is a
sized_memory_description) is:
{size = 32, description = 0x762e40}
and THAT memory_description (0x762e40) points to:
{type = XD_LISP_OBJECT,
offset = 0,
data1 = 0,
data2 = {write_only = 0x0, descr = 0x0, funcs = 0x0},
flags = 0}
Any theories on how that bad pointer got into a kkcc_gc_stack_ptr
element in the first place? I still have the core file.
Regards,
--
Jerry James, Assistant Professor james(a)xemacs.org
Computer Science Department
http://www.cs.usu.edu/~jerry/
Utah State University