Re: GC missed a reference

Re: GC missed a reference

[Bill Schottstaedt]

On the <GC missed a reference> bug reported earilier,
in hashtab.c, in rehash_after_gc, to_rehash is set to
SCM_EOL, the rehash list is processed, then the weak_hashtables
list is set to to_rehash -- this clobbers the entire list!
Subsequent GC's then start freeing everything in every
weak hash table, including the symbol table.

I think the line (287 in the version I have) should be:

       weak_hashtables = last;



_______________________________________________
Bug-guile mailing list
Bug-guile@gnu.org
http://mail.gnu.org/mailman/listinfo/bug-guile

Re: GC missed a reference

[Marius Vollmer]

Bill Schottstaedt <bil@ccrma.Stanford.EDU> writes:

> On the <GC missed a reference> bug reported earilier,
> in hashtab.c, in rehash_after_gc, to_rehash is set to
> SCM_EOL, the rehash list is processed, then the weak_hashtables
> list is set to to_rehash -- this clobbers the entire list!

Ouch, that's clearly a bug.

> I think the line (287 in the version I have) should be:
>
>        weak_hashtables = last;

Hmm, that would only put 'last' back in the list of weak_hashtables.
I think it should be:

      SCM first = to_rehash, last, h;
      /* important to clear to_rehash here so that we don't get stuck
	 in an infinite loop if scm_i_rehash causes GC */
      to_rehash = SCM_EOL;
      h = first;
      do
	{
	  scm_i_rehash (h,
			/* use same hash_fn and closure as last time */
			SCM_HASHTABLE (h)->hash_fn,
			SCM_HASHTABLE (h)->closure,
			"rehash_after_gc");
	  last = h;
	  h = SCM_HASHTABLE_NEXT (h);
	} while (!SCM_NULLP (h));
      /* move tables back to weak_hashtables */
      SCM_SET_HASHTABLE_NEXT (last, weak_hashtables);
      weak_hashtables = first;

I.e., we need to remember the first hashtab originally pointed to by
t_rehash.

Can you try that variant?  I have comitted it to HEAD.

-- 
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3  331E FAF8 226A D5D4 E405


_______________________________________________
Bug-guile mailing list
Bug-guile@gnu.org
http://mail.gnu.org/mailman/listinfo/bug-guile

Re: GC missed a reference

[Bill Schottstaedt]

 > Can you try that variant?  I have comitted it to HEAD.

So far so good -- I'll keep watching for the old troubles (this bug is
not completely repeatable since my giant test suite has a lot of
built-in randomness, and it never happens in simple cases, so it's
hard to be sure about anything).  Your version of the bugfix looks
correct to me.  Thanks!




_______________________________________________
Bug-guile mailing list
Bug-guile@gnu.org
http://mail.gnu.org/mailman/listinfo/bug-guile

Re: GC missed a reference

[Bill Schottstaedt]

On the "#<freed cell 0x40b66060; GC missed a reference>" bug reported
a while ago, I now think the problem is in symbols.c, in the function
scm_mem2symbol, and involves the call of scm_i_rehash.  If I
gc-protect the symbol referred to in the error message (via
scm_permanent_object), or if I comment out the rehash, everything is fine.
I notice that if the symbol table is drastically reduced in size
(after closing a large let, for example), the dead entries may not
always be removed; a subsequent gc leaves the cells in the symbol
table, and scm_cell or someone then reallocates them as a number,
or whatever, so you end up with a symbol table full of non-symbols,
causing havoc for "apropos".  Unfortunately, I have not yet found
a simple case.



_______________________________________________
Bug-guile mailing list
Bug-guile@gnu.org
http://mail.gnu.org/mailman/listinfo/bug-guile

GC missed a reference

[Bill Schottstaedt]

Sorry about this less-than-ideal bug report, but maybe this
will make sense to someone.

In the CVS Guile, but not earlier versions (i.e. not 1.6.4 or any before that),
there is a problem with let: if you have a block with successive lets,
and these lets share a local name, you can get "GC missed a
reference":

wrong-type-arg: (- Wrong type argument in position ~A: ~S (1 #<freed cell 0x40b78e80; GC missed a reference>) #f)

The problem goes away if you rename the local variables so that there
are no shared names.  The bad case is basically:

(let ...
   (let ((var val)
         (var1 val1))
     ...)
   (let ((var val2)
         (var1 val3))
     ...)) ; in this body, you can get the GC missed a ref bug

Change the second "var1" to "var2" and the error goes
away. Unfortunately, I can't seem to find a simple case of this -- my
"regression" test is more than 42000 lines long, and it's not a
completely repeatable problem even without any changes.  It appears
that the 2nd binding needs to be the result of SCM_RETURN_NEWSMOB to
trigger this problem.



_______________________________________________
Bug-guile mailing list
Bug-guile@gnu.org
http://mail.gnu.org/mailman/listinfo/bug-guile