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