> On Fri 18 Mar 2011 12:51, address@hidden (Ludovic CourtÃs) writes:
>
> > michaelawells <address@hidden> writes:
> >
> >>> size_t len = SCM_HASHTABLE_N_ITEMS (table);
> >>>
> >>> while (k--)
> >>> {
> >>> size_t removed;
> >>> SCM alist = SCM_SIMPLE_VECTOR_REF (buckets, k);
> >>> alist = scm_fixup_weak_alist (alist, &removed); <<<**** FAILS HERE
> >>> assert (removed <= len);
> >
> > Andy, isnât this assertion bogus since N_ITEMS is updated lazily and
> > thus may not correspond to the current number of items?
>
> I don't think so; this is the procedure that is doing that lazy sweep.
>
> Michael, how are you using this hash table? Are you accessing it from
> different pthreads? What version of libgc are you using? (Did you
> enable parallel collection?)
Sorry, the "<<<*** FAILS here" note should have been placed after the assert,
not the call to "scm_fixup_weak_alist".
I'm not using weak hash tables in my code. Weak hash tables are used in
modules such as (ice-9 boot-9) and (ice-9 popen), and from C code, such as
libguile/symbols.c.
I'm using gc-7.1. I didn't use any special options when building libgc. I'll
try rebuilding libgc using the "--enable-threads=posix" configure option and
see if I still see the problem. (Is that what you meant by enabling parallel
collection? If so, perhaps the README file should updated to say this is
necessary.)
I'm not using guile from multiple threads, but I am running guile from a thread
in a multi-threaded program. (I've been using guile since before it had
support for multiple threads. So, I constructed the test harness so that guile
is called from a single thread.)
Thanks,
Michael Wells
