unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
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

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