Re: GC crashes

[Kenichi Handa]

In article <jwvllpsh9jh.fsf-monnier+emacs/address@hidden>, Stefan Monnier 
<address@hidden> writes:

>>  I've just found one fact about a weak hash table.  Even
>> if composite.c makes a weak hash table in
>> syms_of_composite (thus it is stored in Vweak_hash_tables
>> and dumped), Vweak_hash_tables is intialized to Qnil in
>> init_fns () at Emacs startup time.

> Ha!  That's a bug.

>>  Does it mean that we should not dump a weak hash table?

> No, it just means we have to change init_fns.

Then, it seems that moving this:
  Vweak_hash_tables = Qnil;
to syms_of_fns is the easiest solution.

>>  Do you think it relates to the current problem?

> Sounds likely.  IIUC the above problem means that the mark
> phase of the GC will (correctly) not look at the
> hash-table's elements (because the table is marked as
> weak), but the elements that get GC'd will not be properly
> removed from the table because that is done via
> Vweak_hash_tables.  I.e. the hash table will end up with
> dangling pointers.

Thank you for the explanation.  I think I know understand
the reason of segfault.

>>>  I guess strictly speaking, the :weak arg should not be
>>> t but `key' so that only the key part is weak,
>>  Does it make difference when the value part is always
>> integer?

> No, it shouldn't.  [ Side note: whether an integer should
> be considered as "always live" or as "always GC-able" from
> the point of view of weakness is not obvious. ]

Ah!  I blindly believed that an integer is always GC-able,
but survives_gc_p (obj) returns 1 if obj is an integer.  So
if we make a composition hash table with :weak t, an element
of the table always survives GC, thus is never removed.  It
doesn't fit my intuition but, I'd like to avoid discussing
on it for the momemnt.

I'll try :weak `key' and check if it really works locally.
It seems that we can't commit anything for a while anyway.

---
Ken'ichi HANDA
address@hidden