[Top][All Lists]
[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
- Re: Fix to long-standing crashes in GC, (continued)
- Re: Fix to long-standing crashes in GC, Richard Stallman, 2004/05/23
- 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 <=
- Re: Fix to long-standing crashes in GC, Stefan Monnier, 2004/05/19
- 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