Re: Fix to long-standing crashes in GC

[Luc Teirlinck <teirllm@dms.auburn.edu>]

Kim Storm wrote:

   I just installed a change which I hope will fix these crashes.
   Please report if you stil experience crashes in mark_object.

I still do and pretty easily in a fully customized Emacs.  If I try to
visit a remote file using Tramp-ssh, I get an immediate crash.  The
fact that the crash is now so immediate can not possibly be due to
your Lisp_Misc_Free change, but several other changes have occurred
since I last updated following Andreas' fix early Saturday (US Central).

When I previously replied, I had not yet updated my CVS and tried out
your fix.  I just _assumed_ that it would "obviously" take care of all
my crashes, because every single one of my many crashes was caused by
a Lisp_Misc_Free type.

The problem seems to be that after a while the data type itself of
these objects seems to get corrupted.  At that stage, your fix does
not work any more, because now they have an _invalid_ data type,
instead of being of type Lisp_Misc_Free.  Then we get the abort anyway.  

Apparently, your fix worked for Robert.  With me, my updated Emacs
crashes immediately when I try to visit a file using Tramp-ssh,
_when using a fully customized Emacs_.  Apparently, one needs enough
"activity" to get these marker types corrupted quickly.  In my fully
customized Emacs, there is much more timer activity than auto-revert.

I have plenty of information and could try to produce a "cleaner"
crash with emacs -q and only a few customizations, but at the moment
I will just give the information that I personally believe is
relevant.  The object with the invalid data type _is_ that same
marker, I recognize the -37.

One could completely fix the crashes by making gc not only fail to
abort when discovering still accessible Lisp objects whose memory has
been freed (as your fix currently does), but when detecting Lisp
objects with invalid data type as well.  I do not know enough about
very low level Emacs stuff like this, but would that not be dangerous?
Should we not try to fix the problem completely differently and try to
find out_why_ the memory for these markers was erroneously freed and
fix _that_ problem?  Then gc could continue to try to detect Lisp
objects whose memory was erroneously freed, which, at first sight,
would seem like a safer thing to do (but then again, I do not know
enough about this to judge).

(gdb) bt
#0  abort () at emacs.c:434
#1  0x0812a589 in mark_object (arg=143587538) at alloc.c:5042
#2  0x0812a5ea in mark_object (arg=143787141) at alloc.c:5059
#3  0x0812a5ea in mark_object (arg=143785989) at alloc.c:5059
#4  0x0812948a in mark_memory (start=0xbfffb6a0, end=0xbffff5ac)
    at alloc.c:3781
#5  0x081294f5 in mark_stack () at alloc.c:4055
#6  0x08129aba in Fgarbage_collect () at alloc.c:4429

(gdb) p last_marked_index
$1 = 18
(gdb) p last_marked[17]
$2 = 143587538
(gdb) pr
#<EMACS BUG: INVALID DATATYPE (MISC 0x0002) Save your buffers immediately and please report this bug>
(gdb) xtype
Lisp_Misc
2
(gdb) xmiscfree
$3 = (struct Lisp_Free *) 0x88ef8d0
(gdb) p *$3
$4 = {
  type = 2, 
  gcmarkbit = 1, 
  spacer = 0, 
  chain = 0x2, 
  padding = "\000\000\000\000<\332\216\b\002\000\000\000\002\000\000"
}
(gdb) p last_marked[16]
$5 = 143787141
(gdb) pr
(#<EMACS BUG: INVALID DATATYPE (MISC 0x0002) Save your buffers immediately and please report this bug> . -37)
(gdb) p last_marked[15]
$6 = 143787133
(gdb) pr
((#<EMACS BUG: INVALID DATATYPE (MISC 0x0002) Save your buffers immediately and please report this bug> . -37) (#<EMACS BUG: INVALID DATATYPE (MISC 0x0000) Save your buffers immediately and please report this bug> . -37) (#<EMACS BUG: INVALID DATATYPE (MISC 0x001c) Save your buffers immediately and please report this bug> . -37) (#<EMACS BUG: INVALID DATATYPE (MISC 0x0000) Save your buffers immediately and please report this bug> . -37) (#<EMACS BUG: INVALID DATATYPE (MISC 0x0020) Save your buffers immediately and please report this bug> . -37) (#<EMACS BUG: INVALID DATATYPE (MISC 0x0000) Save your buffers immediately and please report this bug> . -37) (1 . 58) ("tramp_exit_status 0
" . 1) (#<marker at 21 in *tramp/ssh raven.dms.auburn.edu*> . -20))
(gdb) p last_marked[14]
$7 = -296
(gdb) pr
-37
(gdb) p last_marked[13]
$10 = 143806834
(gdb) pr
#<marker in no buffer>
(gdb) p last_marked[12]
$11 = 143787125
(gdb) pr
(#<marker in no buffer> . -37)
(gdb) p last_marked[11]
$12 = 143787117
(gdb) pr
((#<marker in no buffer> . -37) (#<EMACS BUG: INVALID DATATYPE (MISC 0x0002) Save your buffers immediately and please report this bug> . -37) (#<EMACS BUG: INVALID DATATYPE (MISC 0x0000) Save your buffers immediately and please report this bug> . -37) (#<EMACS BUG: INVALID DATATYPE (MISC 0x001c) Save your buffers immediately and please report this bug> . -37) (#<EMACS BUG: INVALID DATATYPE (MISC 0x0000) Save your buffers immediately and please report this bug> . -37) (#<EMACS BUG: INVALID DATATYPE (MISC 0x0020) Save your buffers immediately and please report this bug> . -37) (#<EMACS BUG: INVALID DATATYPE (MISC 0x0000) Save your buffers immediately and please report this bug> . -37) (1 . 58) ("tramp_exit_status 0
" . 1) (#<marker at 21 in *tramp/ssh raven.dms.auburn.edu*> . -20))
(gdb) p last_marked[10]
$13 = -296
(gdb) pr
-37
(gdb) p last_marked[9]
$14 = 143806858
(gdb) pr
#<marker in no buffer>
(gdb) p last_marked[8]
$15 = 143787109
(gdb) pr
(#<marker in no buffer> . -37)
(gdb) p last_marked[7]
$18 = 143787101
(gdb) pr
((#<marker in no buffer> . -37) (#<marker in no buffer> . -37) (#<EMACS BUG: INV
ALID DATATYPE (MISC 0x0002) Save your buffers immediately and please report this
 bug> . -37) (#<EMACS BUG: INVALID DATATYPE (MISC 0x0000) Save your buffers imme
diately and please report this bug> . -37) (#<EMACS BUG: INVALID DATATYPE (MISC 
0x001c) Save your buffers immediately and please report this bug> . -37) (#<EMAC
S BUG: INVALID DATATYPE (MISC 0x0000) Save your buffers immediately and please r
eport this bug> . -37) (#<EMACS BUG: INVALID DATATYPE (MISC 0x0020) Save your bu
ffers immediately and please report this bug> . -37) (#<EMACS BUG: INVALID DATAT
YPE (MISC 0x0000) Save your buffers immediately and please report this bug> . -3
7) (1 . 58) ("tramp_exit_status 0
" . 1) (#<marker at 21 in *tramp/ssh raven.dms.auburn.edu*> . -20))
(gdb) p last_marked[6]
$19 = -296
(gdb) pr
-37
(gdb) p last_marked[5]
$20 = 143807602
(gdb) pr
#<marker at 14 in sequences.texi>
(gdb) p last_marked[4]
$21 = 143787093
(gdb) pr              
(#<marker at 14 in sequences.texi> . -37)
(gdb) p last_marked[3]
$22 = 143787085
(gdb) pr
((#<marker at 14 in sequences.texi> . -37) (#<marker in no buffer> . -37) (#<mar
ker in no buffer> . -37) (#<EMACS BUG: INVALID DATATYPE (MISC 0x0002) Save your 
buffers immediately and please report this bug> . -37) (#<EMACS BUG: INVALID DAT
ATYPE (MISC 0x0000) Save your buffers immediately and please report this bug> . 
-37) (#<EMACS BUG: INVALID DATATYPE (MISC 0x001c) Save your buffers immediately 
and please report this bug> . -37) (#<EMACS BUG: INVALID DATATYPE (MISC 0x0000) 
Save your buffers immediately and please report this bug> . -37) (#<EMACS BUG: I
NVALID DATATYPE (MISC 0x0020) Save your buffers immediately and please report th
is bug> . -37) (#<EMACS BUG: INVALID DATATYPE (MISC 0x0000) Save your buffers im
mediately and please report this bug> . -37) (1 . 58) ("tramp_exit_status 0
" . 1) (#<marker at 21 in *tramp/ssh raven.dms.auburn.edu*> . -20))
(gdb) p last_marked[2]
$23 = -296
(gdb) pr
-37
(gdb) p last_marked[1]
$24 = 143807626
(gdb) pr
#<marker at 7 in sequences.texi>
(gdb) p last_marked[0]
$25 = 143787077
(gdb) pr
(#<marker at 7 in sequences.texi> . -37)