Re: Fix to long-standing crashes in GC

[Stefan Monnier]

>> Please try finding out *precisely* which stack slot
>> mark_memory is currently examining.  Which stack frame is it in?
>> What variable is it?

> Got it.

> In Feval, it points to the backtrace.evalargs member.

> #4  0x0816cb3e in mark_maybe_pointer (p=0x8970000) at alloc.c:3803

> (gdb) x/32 &backtrace
> 0xbffe6980:   0xbffe6b10      0xbffe69b4      0xbffe69b0      0xffffffff
> 0xbffe6990:   0x08970000      0xbffe6960      0x00000002      0x08185456
>                 ========== here
> 0xbffe69a0:   0xbffe6ac0      0xbffe69d4      0xbffe69d0      0xffffffff
> 0xbffe69b0:   0x087a3815      0x084458b9      0x08947f55      0x083eb11c
> 0xbffe69c0:   0xbffe6b10      0xbffe69f4      0xbffe6a08      0x0818127d
> 0xbffe69d0:   0x087a382d      0x084458e9      0x088c96f9      0x083eb14c
> 0xbffe69e0:   0x082188bc      0x08947f3d      0xbffe6a28      0x08430d79
> 0xbffe69f0:   0x087a38c5      0x08446a81      0x085e3725      0x08430d91

> struct backtrace
> {
>   struct backtrace *next;
>   Lisp_Object *function;
>   Lisp_Object *args;  /* Points to vector of args. */
>   int nargs;          /* Length of vector.
>                          If nargs is UNEVALLED, args points to slot holding
>                          list of unevalled args */
>   char evalargs;
>   /* Nonzero means call value of debugger when done with this operation. */
>   char debug_on_exit;
> };

> So setting evalargs and debug_on_exit clears the lower part of the
> Lisp_Object which happened to be on the stack on entry, but not the rest
> of it, so it points into a legal cons_block cell, but one which probably
> isn't in use anymore.

> I will install a fix for this specific issue shortly.

Please show us the fix first.

> However, this reveals a more serious issue:

> YOU REALLY CANNOT RELY 100% ON STACK POINTERS ACTUALLY
> POINTING TO VALID DATA.

But that's already checked:
mark_memory calls makr_maybe_object and makr_maybe_pointer, but of which
check for every object whether it's currently live (which really means
"allocated" in the sense that it hasn't been reclaimed by the GC yet).
That's what live_consp_, live_stringp_p, ... are for.

> Here is the data pointed to by the offending stack pointer:

> ((#<marker at 1 in HISTORY> . -37)
>  (#<marker at 44 in HISTORY> . -37)
>  (#<marker at 44 in HISTORY> . -37)
>  (#<misc free cell> . -37)
>  (#<misc free cell> . -37)
>  (#<misc free cell> . -37)

I strongly suspect that we're looking at a consequence of another bug.
Either this cons cell (pointed to by evalargs) is indeed live and then it
should not lead to any misc_free object, or it is incorrectly considered as
live (maybe because of a bug in live_cons_p, or because of a bug in the
code that marks cons cells as dead in gc_sweep, or because of some wild
pointer overwriting the corresponding data, ...).


        Stefan