[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Fix to long-standing crashes in GC
From: |
Stefan Monnier |
Subject: |
Re: Fix to long-standing crashes in GC |
Date: |
19 May 2004 15:32:22 -0400 |
User-agent: |
Gnus/5.09 (Gnus v5.9.0) Emacs/21.3.50 |
>> 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
- Re: Fix to long-standing crashes in GC, (continued)
- Re: Fix to long-standing crashes in GC, Kim F. Storm, 2004/05/24
- Re: Fix to long-standing crashes in GC, Stefan Monnier, 2004/05/28
- Re: Fix to long-standing crashes in GC, Kim F. Storm, 2004/05/29
- Re: Fix to long-standing crashes in GC, Stefan Monnier, 2004/05/29
- Re: Fix to long-standing crashes in GC, Kim F. Storm, 2004/05/29
- Re: Fix to long-standing crashes in GC, Stefan Monnier, 2004/05/30
- Re: Fix to long-standing crashes in GC, Kim F. Storm, 2004/05/31
- Re: Fix to long-standing crashes in GC, Richard Stallman, 2004/05/20
- Re: Fix to long-standing crashes in GC, Stefan Monnier, 2004/05/22
- Re: Fix to long-standing crashes in GC, Kim F. Storm, 2004/05/19
- Re: Fix to long-standing crashes in GC,
Stefan Monnier <=
- Re: Fix to long-standing crashes in GC, Kim F. Storm, 2004/05/19
- Re: Fix to long-standing crashes in GC, Richard Stallman, 2004/05/20
Re: Fix to long-standing crashes in GC, Robert Anderson, 2004/05/13