Re: Fix to long-standing crashes in GC

[Stefan Monnier <monnier@iro.umontreal.ca>]

>> 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