Re: Emacs crashes

[Richard Stallman]

     > The fact that there are thousands of recursive calls to mark_object is
     > not in itself a sign of a problem.  It is normal for the mark phase to
     > be deeply recursive.

    OK, I didn't know that.  Perhaps I should look at the bottom of the 
backtrace
    (i.e low frame nos) instead of the top.

That would be useful if you want to see what Emacs was doing when it
garbage collected, so as to see what recent previous activity might
have been responsible for the clobberage.

However, for finding out what data was clobbered, you need to look at
the innermost frames.  Finding out what data was clobbered is often useful
because often the clobberage is not entirely random.  It may, for instance,
be an overrun problem affecting the data immediately before in memory.

    $5 = (struct Lisp_Cons *) 0xa0024e8
    {
      car = 0x4, 
      u = {
        cdr = 0xffffffff, 
        chain = 0xffffffff
      }
    }

    These last addresses looks suspect I don't know what to do next.

It seems definitely invalid.

So we know that the code that clobbers can store -1.  That may be useful.
Is it always -1?

However, it seems clear that all the other data near this one are cons
cells too.  And cons cell slots are only used as cons cells.  An
overrun on a nearby cons cell seems rather implausible as a source of
error.