Re: crash backtrace

[Chris Moore]

Richard Stallman writes:

 > If you can find a reliable way to make this crash, that would be
 > extremely useful.

First off, I saw the same problem happen when I was trying to visit a
huge file on my hard disk without using the 'tramp' stuff.  It's
probable that I had already loaded tramp, however.

Secondly, I've found a reliable way to make the problem disappear:
removing ~/share/emacs/21.3.50/lisp/net/tramp.elc 'fixes' it.  I can
now visit the huge file without any crashes.

The tramp.elc that was there was compiled with an Emacs built from CVS
on 3rd Feb this year.  Recompiling tramp.el with an up-to-date version
of Emacs from CVS makes the problem come back again.

I am able to reproduce the crash every time now.  I put a "'(" at the
start of my existing .emacs file and a ")" at the end, to "quote" the
whole file.  I then preceded the giant quoted list with this:

 | (let ((cnt 0))
 |   (while t
 |     (find-file "/su:address@hidden:~/.emacs")
 |     ;; (find-file "~/.emacs")
 |     (kill-buffer ".emacs")
 |     (set-buffer "*scratch*")
 |     (delete-region (point-min) (point-max))
 |     (setq cnt (1+ cnt))
 |     (insert (format "iteration %d" cnt))
 |     (sit-for 0)))

a loop that will re-visit my .emacs over and over until it crashes.
The loop is almost unneccesary, because it always crashes on the
first time through the loop.  However, if I remove the loop code then
it doesn't crash.  Also, if I change or delete the quoted stuff in
the rest of my .emacs then the crash becomes a lot less repeatable.
It might crash on the 200th iteration for instance.  If I make a
mistake when typing my password and correct it, then the crash
sometimes doesn't happen.  It's an unstable crash...

Look at #5 in this stack trace:

 | #0  0x40339d71 in kill () from /lib/i686/libc.so.6
 | #1  0x080e5826 in abort () at emacs.c:424
 | #2  0x08134035 in mark_object (arg=0) at alloc.c:5067
 | #3  0x08134014 in mark_object (arg=0) at alloc.c:5050
 | #4  0x08134014 in mark_object (arg=0) at alloc.c:5050
 | #5  0x0813324e in mark_memory (start=0x8757400, end=0xbffff5fc) at 
alloc.c:3830
 | #6  0x081332ca in mark_stack () at alloc.c:4054
 | #7  0x0813384c in Fgarbage_collect () at alloc.c:4428

start=0x8757400, it says.  this looks like stack corruption to me.

I made a breakpoint like this:

 | break mark_memory if start<0xb0000000

before start emacs.  It never triggers.  (I'm no gdb expert, but
shouldn't it, if mark_memory was really called with start=0x8757400
?)

 > Meanwhile, if you could study the code
 > and figure out which slot in which stack frame
 > was being marked here, and why marking this data led to a crash,
 > that would be quite useful.
 > 
 >     #5  0x0812e98e in mark_memory (start=0x87dfc00, end=0xbffff65c)
 >      at /home/chris/emacs/src/emacs/src/alloc.c:3830
 >     #6  0x0812ea0a in mark_stack () at 
 > /home/chris/emacs/src/emacs/src/alloc.c:4054

I don't understand why start is so low.  That's only 7 digits.

The code which uses start, in mark_memory(), in alloc.c says:

  for (pp = (void **) start; (void *) pp < end; ++pp)
    mark_maybe_pointer (*pp);

and GDB tells me:

 | #5  0x0813324e in mark_memory (start=0x8756c00, end=0xbffff5fc) at 
alloc.c:3830
 | 3830        mark_maybe_pointer (*pp);
 | (gdb) print pp
 | $9 = (void **) 0xbfffbf04

pp, initialised from start, seems to hold a reasonable value - not
far from the base of the stack.  I don't believe that 'start' was
really so low, but how can I debug this, or help someone else debug
it?

Chris.