[Bug: 21.5-b26+CVS] Crash in GC

[Jerry James]

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 at xemacs.org
Computer Science Department             http://www.cs.usu.edu/~jerry/
Utah State University