Re: GC crashes

[storm@cua.dk (Kim F. Storm)]

Juri Linkov <juri@jurta.org> writes:

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

Please do -- I know there is a memory corruption issue somewhere but
so far nobody's been able to identify under what circumstances they
happen.

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

Sounds like it points to the obarray or some such.  But probably the
pointer to the symbol is bogus, so someone wrote over that pointer,
so maybe you could look at where that pointer came from and see what
data is around there (to see if any other data there gives a clue
to what part of the code wrote over it).

>       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?

You can try changing the #if 0 at line 32 in lisp.h to #if 1, remove
all *.o files, rebuild emacs, and see if it catches the bug before it
happens (it will still abort emacs, but you can look at the data to
see what may be causing the memory overwrite).


>
> (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}
> }
> ...
-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk