From: storm@cua.dk (Kim F. Storm)
Cc: Luc Teirlinck <teirllm@dms.auburn.edu>, emacs-devel@gnu.org
Subject: Re: Fix to long-standing crashes in GC
Date: 19 May 2004 14:11:42 +0200 [thread overview]
Message-ID: <m37jv8boqp.fsf@kfs-l.imdomain.dk> (raw)
In-Reply-To: <E1BQFr5-0001yZ-5x@fencepost.gnu.org>
Richard Stallman <rms@gnu.org> 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
next prev parent reply other threads:[~2004-05-19 12:11 UTC|newest]
Thread overview: 55+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-05-13 18:19 Fix to long-standing crashes in GC Lars Hansen
2004-05-13 19:09 ` Luc Teirlinck
2004-05-13 19:29 ` Luc Teirlinck
2004-05-13 19:30 ` Lars Hansen
2004-05-13 19:19 ` Stefan Monnier
2004-05-13 22:16 ` Luc Teirlinck
2004-05-13 23:04 ` Stefan Monnier
2004-05-14 11:42 ` Kai Grossjohann
2004-05-14 14:53 ` Luc Teirlinck
2004-05-14 20:48 ` Kai Grossjohann
2004-05-16 9:27 ` Kai Grossjohann
2004-05-14 18:39 ` Luc Teirlinck
2004-05-14 20:54 ` Kim F. Storm
2004-05-14 21:02 ` Richard Stallman
2004-05-22 18:09 ` Lars Hansen
2004-05-23 16:33 ` Eli Zaretskii
2004-05-23 16:32 ` Luc Teirlinck
2004-05-23 17:11 ` Lars Hansen
2004-05-24 5:30 ` Eli Zaretskii
2004-05-25 3:03 ` Luc Teirlinck
2004-05-25 7:07 ` Eli Zaretskii
2004-05-15 4:39 ` Robert Marshall
2004-05-17 14:39 ` Kim F. Storm
2004-05-17 17:42 ` Robert Marshall
2004-05-17 14:43 ` Kim F. Storm
2004-05-18 0:13 ` Luc Teirlinck
2004-05-19 1:26 ` Richard Stallman
2004-05-19 12:11 ` Kim F. Storm [this message]
2004-05-19 19:32 ` Stefan Monnier
2004-05-19 22:33 ` Kim F. Storm
2004-05-20 13:17 ` Richard Stallman
2004-05-19 12:52 ` Kim F. Storm
2004-05-19 16:48 ` Stefan Monnier
2004-05-19 22:04 ` Kim F. Storm
2004-05-19 22:25 ` Stefan Monnier
2004-05-19 22:37 ` Kim F. Storm
2004-05-19 22:50 ` Stefan Monnier
2004-05-20 0:44 ` Kim F. Storm
2004-05-21 23:43 ` Kim F. Storm
2004-05-23 1:14 ` Stefan Monnier
2004-05-23 18:28 ` Richard Stallman
2004-05-24 11:57 ` Kim F. Storm
2004-05-28 21:51 ` Stefan Monnier
2004-05-28 23:40 ` Kim F. Storm
2004-05-28 23:49 ` Stefan Monnier
2004-05-29 23:15 ` Kim F. Storm
2004-05-30 20:44 ` Stefan Monnier
2004-05-31 20:21 ` Kim F. Storm
2004-06-08 20:03 ` Lars Hansen
2004-05-20 7:08 ` Richard Stallman
2004-05-21 22:58 ` Stefan Monnier
-- strict thread matches above, loose matches on Subject: below --
2004-05-13 23:34 Robert Anderson
2004-05-12 13:19 Kim F. Storm
2004-05-13 13:06 ` Kenichi Handa
2004-05-13 15:45 ` Richard Stallman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=m37jv8boqp.fsf@kfs-l.imdomain.dk \
--to=storm@cua.dk \
--cc=emacs-devel@gnu.org \
--cc=teirllm@dms.auburn.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).