GC crashes (Was: Items in FOR-RELEASE)

[Juri Linkov <juri@jurta.org>]

Stefan Monnier <monnier@iro.umontreal.ca> writes:
> It's more important that we release it soon than it is to include
> each and every new feature.

It seems in its current state Emacs is too far from being ready for
the release.  In the last three months Emacs became too unstable:
I have experienced frequent crashes in GC (I had no crashes before
September 2004).  I haven't debugged them because debugging GC looks
to me like brain surgery.  However, unless this is a known problem,
I might try to debug it.

PS: The latest crash I got was just when composing the previous reply.
I attached the debug session below if it might help somehow.
The cause of the crash is the fact that symbol's `xname' contains
a vector.  I've looked at the contents of this vector, and it has the
values of variables `load-path' `user-init-file', `byte-boolean-vars',
etc.  The symbol's `value', `function' and `plist' have some absurd
values.  This looks like a memory corruption.  Could compiling with
ENABLE_CHECKING or other compiler options help detect where memory
corruption occurs?

(gdb) bt
#0  mark_object (arg=137262137) at alloc.c:5193
#1  0x0812490e in mark_object (arg=165544885) at alloc.c:5301
#2  0x0812136c in mark_interval (i=0x9e15a64, dummy=137262265) at alloc.c:1356
#3  0x0816bc39 in traverse_intervals_noorder (tree=0x9e15a10, function=0x8121354 <mark_interval>, arg=137262265) at intervals.c:207
#4  0x0816bc54 in traverse_intervals_noorder (tree=0x9e15394, function=0x8121354 <mark_interval>, arg=137262265) at intervals.c:212
#5  0x0816bc54 in traverse_intervals_noorder (tree=0x9e14abc, function=0x8121354 <mark_interval>, arg=137262265) at intervals.c:212
#6  0x0816bc54 in traverse_intervals_noorder (tree=0x9e16788, function=0x8121354 <mark_interval>, arg=137262265) at intervals.c:212
#7  0x0816bc54 in traverse_intervals_noorder (tree=0x9e12198, function=0x8121354 <mark_interval>, arg=137262265) at intervals.c:212
#8  0x0816bc54 in traverse_intervals_noorder (tree=0x9e131e8, function=0x8121354 <mark_interval>, arg=137262265) at intervals.c:212
#9  0x0812138c in mark_interval_tree (tree=0x9e131e8) at alloc.c:1371
#10 0x081249a4 in mark_buffer (buf=156504092) at alloc.c:5338
#11 0x0812401a in mark_object (arg=156504092) at alloc.c:5028
[...1500 more frames...]
(gdb) xba
"font-lock-fontify-keywords-region"
"font-lock-default-fontify-region"
"font-lock-fontify-region"
"run-hook-with-args"
"byte-code"
"jit-lock-fontify-now"
"byte-code"
"jit-lock-stealth-fontify"
"apply"
"byte-code"
"timer-event-handler"
(gdb) fr 0
#0  mark_object (arg=137262137) at alloc.c:5193
5193              MARK_STRING (XSTRING (ptr->xname));
(gdb) p ptr
$3 = (struct Lisp_Symbol *) 0x82a0ba0
(gdb) p *$
$4 = {
  gcmarkbit = 0, 
  indirect_variable = 0, 
  constant = 1, 
  interned = 0, 
  xname = 137228604, 
  value = 137199748, 
  function = 137199744, 
  plist = 137199772, 
  next = 0x82d7008
}
(gdb) p ptr->xname
$5 = 137228604
(gdb) xtype
Lisp_Vectorlike
167653757
(gdb) xvector
$6 = (struct Lisp_Vector *) 0x82df138
0
(gdb) p *$
$7 = {
  size = 167653757, 
  next = 0x82e7501, 
  contents = {143577373}
}
...

-- 
Juri Linkov
http://www.jurta.org/emacs/