* GC missed a reference
@ 2004-01-26 11:26 Bill Schottstaedt
0 siblings, 0 replies; 5+ messages in thread
From: Bill Schottstaedt @ 2004-01-26 11:26 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: GC missed a reference
@ 2004-04-25 11:09 Bill Schottstaedt
0 siblings, 0 replies; 5+ messages in thread
From: Bill Schottstaedt @ 2004-04-25 11:09 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: GC missed a reference
@ 2004-04-28 16:25 Bill Schottstaedt
2004-05-18 21:22 ` Marius Vollmer
0 siblings, 1 reply; 5+ messages in thread
From: Bill Schottstaedt @ 2004-04-28 16:25 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: GC missed a reference
2004-04-28 16:25 Bill Schottstaedt
@ 2004-05-18 21:22 ` Marius Vollmer
2004-05-19 16:06 ` Bill Schottstaedt
0 siblings, 1 reply; 5+ messages in thread
From: Marius Vollmer @ 2004-05-18 21:22 UTC (permalink / raw)
Cc: bug-guile
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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: GC missed a reference
2004-05-18 21:22 ` Marius Vollmer
@ 2004-05-19 16:06 ` Bill Schottstaedt
0 siblings, 0 replies; 5+ messages in thread
From: Bill Schottstaedt @ 2004-05-19 16:06 UTC (permalink / raw)
Cc: bug-guile
> 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
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2004-05-19 16:06 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2004-01-26 11:26 GC missed a reference Bill Schottstaedt
-- strict thread matches above, loose matches on Subject: below --
2004-04-25 11:09 Bill Schottstaedt
2004-04-28 16:25 Bill Schottstaedt
2004-05-18 21:22 ` Marius Vollmer
2004-05-19 16:06 ` Bill Schottstaedt
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).