Re: GC bug

[Alex Schroeder]

It just happened again, so I will try to follow your instructions.  I
did not recompile without -O, yet.

Program received signal SIGABRT, Aborted.
0x40248a51 in kill () from /lib/libc.so.6
(gdb) bt
#0  0x40248a51 in kill () from /lib/libc.so.6
#1  0x080d5b1a in abort () at emacs.c:417
#2  0x0811d245 in mark_object (argptr=0xbfffdb04) at alloc.c:4862
#3  0x0811bc1d in mark_memory (start=0xbfffdb3c, end=0xbffff9c4) at alloc.c:3453
#4  0x0811c082 in mark_stack () at alloc.c:3835
#5  0x0811c655 in Fgarbage_collect () at alloc.c:4207
#6  0x081568c5 in Fbyte_code (bytestr=958620596, vector=1227096944, 
maxdepth=16) at bytecode.c:543

Richard Stallman <address@hidden> writes:

> One thing to check is the value of stack_base.  Is it correct?

(gdb) p stack_base
$1 = (int *) 0xbffff9c4

I'm guessing that I should not use pr in this situation, according to
etc/DEBUG.

>     #3  0x0811bc1d in mark_memory (start=0xbfff9db0, end=0xbffff9c4) at 
> alloc.c:3453
>
> Are the values of start and end reasonable values?

How would I know?  My machine has 128M RAM, ps says something like
this:

~% ps aux
USER       PID %CPU %MEM   VSZ  RSS TTY      STAT START   TIME COMMAND
...
alex       447  3.0 26.3 38768 33564 tty1    TN   Jun12  15:23 emacs -geometry 
150x55
...

>     #2  0x0811d245 in mark_object (argptr=0xbfff9d78) at alloc.c:4862
>
> Which stack frame is address 0xbfff9d78 in?
> Do `i frame' in each stack frame to see which one
> contains that address.

Ok, in the current example, I am looking for 0xbfffdb04.

I'm not sure What you mean by "contains that address".  I saw the
value here, but I guess that's obvious.  I didn't know what I was
looking for.  It seemed to me that the further up I went in the stack
frames, to father the numbers I saw seemed to be from 0xbfffdb04.

(gdb) i frame
Stack level 2, frame at 0xbfffdab8:
 eip = 0x811d245 in mark_object (alloc.c:4862); saved eip 0x811bc1d
 called by frame at 0xbfffdb08, caller of frame at 0xbfffda88
 source language c.
 Arglist at 0xbfffdab8, args: argptr=0xbfffdb04
 Locals at 0xbfffdab8, Previous frame's sp in esp
 Saved registers:
  ebx at 0xbfffda90, ebp at 0xbfffdab8, esi at 0xbfffda94, edi at 0xbfffda98, 
eip at 0xbfffdabc

I kept issuing the following commands until I reached stack level 71,
at which point it would no longer go up.

up
i frame

The addresses seemed to increase linearly.  Here a small sample to
give you an impression, stepping through 10 frames at a time.

Stack level 12, frame at 0xbfffdf18:
 eip = 0x8156abc in Fbyte_code (bytecode.c:710); saved eip 0x812fc61
 called by frame at 0xbfffdf58, caller of frame at 0xbfffde98
 source language c.
 Arglist at 0xbfffdf18, args: bytestr=945555332, vector=1213993416, maxdepth=6
 Locals at 0xbfffdf18, Previous frame's sp in esp
 Saved registers:
  ebx at 0xbfffded0, ebp at 0xbfffdf18, esi at 0xbfffded4, edi at 0xbfffded8, 
eip at 0xbfffdf1c
(gdb) up 10
#22 0x0812f1a2 in Frun_hook_with_args (nargs=3, args=0xbfffe2a4) at eval.c:2287
2287      return run_hook_with_args (nargs, args, to_completion);
(gdb) i frame
Stack level 22, frame at 0xbfffe238:
 eip = 0x812f1a2 in Frun_hook_with_args (eval.c:2287); saved eip 0x812f6a6
 called by frame at 0xbfffe288, caller of frame at 0xbfffe218
 source language c.
 Arglist at 0xbfffe238, args: nargs=3, args=0xbfffe2a4
 Locals at 0xbfffe238, Previous frame's sp in esp
 Saved registers:
  ebp at 0xbfffe238, eip at 0xbfffe23c
(gdb) up 10
#32 0x08156abc in Fbyte_code (bytestr=941860928, vector=1210296420, maxdepth=4) 
at bytecode.c:710
710                 TOP = Ffuncall (op + 1, &TOP);
(gdb) i frame
Stack level 32, frame at 0xbfffe5b8:
 eip = 0x8156abc in Fbyte_code (bytecode.c:710); saved eip 0x812edb4
 called by frame at 0xbfffe658, caller of frame at 0xbfffe548
 source language c.
 Arglist at 0xbfffe5b8, args: bytestr=941860928, vector=1210296420, maxdepth=4
 Locals at 0xbfffe5b8, Previous frame's sp in esp
 Saved registers:
  ebx at 0xbfffe570, ebp at 0xbfffe5b8, esi at 0xbfffe574, edi at 0xbfffe578, 
eip at 0xbfffe5bc

I then tried to find a way to grep for this, somehow.
So I did a 'bt full' and copied the output into a file, and ran grep
on it, looking for numbers smaller or equal to 0xbfffdb04

~% grep 'bfff\([0123456789abc]\|d[456789ab]\)' full-bt  
#2  0x0811d245 in mark_object (argptr=0xbfffdb04) at alloc.c:4862
#3  0x0811bc1d in mark_memory (start=0xbfffdb3c, end=0xbffff9c4) at alloc.c:3453
        end = (void *) 0xbfffdb3c

> Then find what data structure is that in.
> In that frame, try doing `info local' and determine the address
> and size of various locals.  Likewise for the arguments.
> With that info, we may see what's going on.

Thus, I was unable to find the address.

> Try x/x 0xbfff9d78; that way you will reliably see
> what is at that location.  I suspect from the code in mark_object
> that it is a Lisp_Misc type.  Which kind?

Ok, looking for 0xbfffdb04:

(gdb) x/x 0xbfffdb04
0xbfffdb04:     0x5938dcb4
(gdb) xtype
Argument to arithmetic operation not a number or boolean.

> Try to deduce out what happened inside the code for mark_maybe_object.
> If you can't deduce it, try recompiling without -O and after removing
> the `INLINE' from the definition of mark_maybe_object.  Then you will
> be able to look at its stack frame and maybe figure out what happened
> there.

I will try that; just looking at the code did not result in
enlightenment.

Alex.
-- 
http://www.emacswiki.org/cgi-bin/alex.pl