Re: GC crashes

[Kenichi Handa]

In article <jwvwu9fnq88.fsf-monnier+emacs/address@hidden>, Stefan Monnier 
<address@hidden> writes:
>>  Thank you.  It's a useful information.  Now I can reproduce
>>  the similar misterious segfault in GC without process nor
>>  code conversion.  I've just installed the attached change.
>>  It seems that it fixes the problem, but I still don't
>>  understand why a week hash table causes a problem.  Anyway,
>>  could you please try again with the latest CVS HEAD?

> Could you give us a brief description of what the table is used for,
> how it's used, how it relates to the crash, as well as a description
> of the crash (way to reproduce it, backtrace, ...) ?

We put `composition' property to text to compose characters
on displaying.  The property value is a list that controls
how to compose characters.

The composition hash table is used for two purpose.

(1) It is not that fast to parse the property value and
    generate a C structure (struct composition) that can be
    directly used by the display routine.  So, eash such C
    structure is stored in an internal table (composition
    table) and the hash table is used to quickly map a
    property value to an index into the composition table.

(2) To reduce the number of conses, if the property value is
    the same (`equal') as what stored as a key in the hash
    table, replace the property value with the key.

If the composition hash table is weak, GC can remove
key-value pair from the table when a text that contains key
as `composition' property is deleted (for instance by
killing a buffer).

The crash can be preproduced by this Emacs
    GNU Emacs 21.3.50.77 (i686-pc-linux-gnu, X toolkit, Xaw3d scroll bars)
by doing this (of course by undoing my fix):

C-u C-h t thai RET
C-v (repeatedly until you reach the bottom)
C-x k RET
M-x garbage-collect RET
C-u C-h t thai RET
C-v (repeatedly)

You'll encounter segfault before you reach the bottom.

(gdb) bt
#0  0x4030f781 in kill () from /lib/libc.so.6
#1  0x080d983a in abort () at emacs.c:417
#2  0x08121055 in mark_object (arg=-67117202) at alloc.c:5046
#3  0x08120e4b in mark_object (arg=-1466419800) at alloc.c:4923
#4  0x0811dd48 in mark_interval (i=0x865b518, dummy=675020556) at alloc.c:1191
#5  0x0816a3e9 in traverse_intervals_noorder (tree=0x865b518, 
    function=0x811dd30 <mark_interval>, arg=675020556) at intervals.c:207
#6  0x0816a404 in traverse_intervals_noorder (tree=0x865b4fc, 
    function=0x811dd30 <mark_interval>, arg=675020556) at intervals.c:212
#7  0x0816a404 in traverse_intervals_noorder (tree=0x865b534, 
    function=0x811dd30 <mark_interval>, arg=675020556) at intervals.c:212
#8  0x0816a404 in traverse_intervals_noorder (tree=0x865b278, 
    function=0x811dd30 <mark_interval>, arg=675020556) at intervals.c:212
#9  0x0816a404 in traverse_intervals_noorder (tree=0x865b738, 
    function=0x811dd30 <mark_interval>, arg=675020556) at intervals.c:212
#10 0x0816a404 in traverse_intervals_noorder (tree=0x8925244, 
    function=0x811dd30 <mark_interval>, arg=675020556) at intervals.c:212
#11 0x0811dd68 in mark_interval_tree (tree=0x8925244) at alloc.c:1206
#12 0x08121094 in mark_buffer (buf=-2007051104) at alloc.c:5066
[...]

This segfault always happens while marking a buffer that
contains `composition' property (in the above case, it's
TUTORIAL.th).  So, I doubted the composition hash table and
made it strong, then the segfault disappeared.

---
Ken'ichi HANDA
address@hidden