emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Fix to long-standing crashes in GC


From: Kim F. Storm
Subject: Re: Fix to long-standing crashes in GC
Date: 19 May 2004 14:11:42 +0200
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3.50

Richard Stallman <address@hidden> writes:

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


However, this reveals a more serious issue:

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

When traversing down a stack pointer object, you may end up in areas
of the memory which has been reused for other purposes (so it is
still "valid" Lisp data, but not of the right type).

So the simplest thing - IMO - is to silently ignore unrecognized items
while scanning through the stack -- In the present case, there
probably isn't anything wrong anywhere, GC just happens to stumble
into reused memory.

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)
 (#<misc free cell> . -37)
 (#<misc free cell> . -37)
 (#<misc free cell> . -37)
 (#<marker in no buffer> . -37)
 (#<marker in no buffer> . -37)
 (#<marker in no buffer> . -37)
 (#<marker in no buffer> . -37)
 (#<marker in no buffer> . -37)
 (#<marker in no buffer> . -37)
 (#<marker in no buffer> . -37)
 (#<marker in no buffer> . -37)
 (#<marker in no buffer> . -37)
 (#<marker in no buffer> . -37)
 (#<marker in no buffer> . -37)
 (#<marker in no buffer> . -37)
 (#<marker in no buffer> . -37)
 (#<marker in no buffer> . -37)
 (#<marker in no buffer> . -37)
 (#<marker in no buffer> . -37)
 (#<marker in no buffer> . -37)
 (#<marker in no buffer> . -37)
 (#<marker in no buffer> . -37)
 (#<marker in no buffer> . -37)
 (#<EMACS BUG: INVALID DATATYPE (MISC 0x0d79) Save your buffers immediately and 
please report this bug> . -37)
 (#<EMACS BUG: INVALID DATATYPE (MISC 0x0d79) Save your buffers immediately and 
please report this bug> . -37)
 (#<EMACS BUG: INVALID DATATYPE (MISC 0x27fc) Save your buffers immediately and 
please report this bug> . -37)
 (#<EMACS BUG: INVALID DATATYPE (MISC 0xffffddb9) Save your buffers immediately 
and please report this bug> . -37)
 (#<EMACS BUG: INVALID DATATYPE (MISC 0xffffddb9) Save your buffers immediately 
and please report this bug> . -37)
 (#<misc free cell> . -37) (1 . 58) ("
///00db4cb378364b4e7fcfd7777f3c1b1f
" . 1) (#<marker at 41 in *tramp/ssh 222.5.4.127*> . -37) (1 . 38) 
("tramp_exit_status 0
(nil 1 500 501 (16555 37172) (15086 40970) (16442 20332) 4705 33204 t (25 . 
3297) -1)
" . 1) (#<marker at 41 in *tramp/ssh 222.5.4.127*> . -106) (21 . 107) ("
///00db4cb378364b4e7fcfd7777f3c1b1f
" . 21) (#<marker at 41 in *tramp/ssh 222.5.4.127*> . -37) (1 . 58) 
("tramp_exit_status 0
" . 1) (#<marker at 41 in *tramp/ssh 222.5.4.127*> . -20) ("
///00db4cb378364b4e7fcfd7777f3c1b1f
" . 21) (#<marker at 41 in *tramp/ssh 222.5.4.127*> . -37) (1 . 58) 
("tramp_exit_status 0
" . 1) (#<marker at 41 in *tramp/ssh 222.5.4.127*> . -20) ("
///00db4cb378364b4e7fcfd7777f3c1b1f
" . 21) (#<marker at 41 in *tramp/ssh 222.5.4.127*> . -37) (1 . 58) 
("tramp_exit_status 0
" . 1) (#<marker at 41 in *tramp/ssh 222.5.4.127*> . -20) ("
///00db4cb378364b4e7fcfd7777f3c1b1f
" . 21) (#<marker at 41 in *tramp/ssh 222.5.4.127*> . -37) (1 . 58) 
("tramp_exit_status 0
" . 1) (#<marker at 41 in *tramp/ssh 222.5.4.127*> . -20) ("
///00db4cb378364b4e7fcfd7777f3c1b1f
" . 21) (#<marker at 41 in *tramp/ssh 222.5.4.127*> . -37) (1 . 58) ("
///00db4cb378364b4e7fcfd7777f3c1b1f
" . 1) (#<marker at 41 in *tramp/ssh 222.5.4.127*> . -37) (1 . 38) 
("tramp_exit_status 0
(nil 1 500 501 (16555 37172) (15086 40970) (16442 20332) 4705 33204 t (25 . 
3297) -1)
" . 1) (#<marker at 41 in *tramp/ssh 222.5.4.127*> . -106) (21 . 107) ("
///00db4cb378364b4e7fcfd7777f3c1b1f
" . 21) (#<marker at 41 in *tramp/ssh 222.5.4.127*> . -37) (1 . 58) 
("tramp_exit_status 0
" . 1) (#<marker at 41 in *tramp/ssh 222.5.4.127*> . -20) ("
///00db4cb378364b4e7fcfd7777f3c1b1f
" . 21) (#<marker at 41 in *tramp/ssh 222.5.4.127*> . -37) (1 . 58) 
("tramp_exit_status 0
" . 1) (#<marker at 41 in *tramp/ssh 222.5.4.127*> . -20) ("
///00db4cb378364b4e7fcfd7777f3c1b1f
" . 21) (#<marker at 41 in *tramp/ssh 222.5.4.127*> . -37) (1 . 58)
 ("(nil 1 500 501 (16555 37172) (15086 40970) (16442 20332) 4705 33204 t (25 . 
3297) -1)
" . 1) (#<marker at 41 in *tramp/ssh 222.5.4.127*> . -86))


--
Kim F. Storm  http://www.cua.dk





reply via email to

[Prev in Thread] Current Thread [Next in Thread]