bug#19180: guile bug#19180: vacuum_weak_hash_table error

[Linas Vepstas]

Anand, I've been using guile, straight from git for maybe almost 2 years(??) in a semi-harsh environment (lots of threads, lots of C++ smob jiggery-pokery, entering and exiting guile, redirecting ports, using fluids at the scheme/c++ boundary, catching and throwing exceptions to/from C++, interleaving all this with python, too, -- and medium cpu burn over many days/week) and it seems to work fine.  Try it -- fix a tag, run system test, I bet it will work for you.  I think Ludo and Andy have done a good job.

The only recent glitch is that the setvbuf API changed.  An old quasi-issue is that garbage collection seems to not be aggressive enough.  After several layers of C calling guile calling C and so on, mem usage seems to bloat (a lot -- many many GB's) unless I forcibly run GC every 50th time I re-enter guile. But I think it does that in guile-2.0 too.

--linas

On Wed, Jun 22, 2016 at 10:43 AM, Anand Mohanadoss <address@hidden> wrote:

Hi Andy,

Thanks a lot for looking into this and your response!  Any idea when we will have a stable 2.2 release that we can move to given that 2.1 has been out for a few months.

Thanks,

Anand

On Wed, Jun 22, 2016 at 8:25 PM, Andy Wingo <address@hidden> wrote:

Hi :)

On Mon 15 Dec 2014 07:36, Anand Mohanadoss <address@hidden> writes:

> Here is what we changed in hashtab.c -
>
> 130a131
>> size_t orig_len = len;
> 137,138c138,144
> < assert (removed <= len);
> < len -= removed;
> ---
>> if (removed <= len)
>> len -= removed;
>> else
>> {
>> printf ("Vacuum weak hash table assert Table=%p len=%zi removed=%zi
> orig_len=%zi n_items=%zi\n", table, len, removed, orig_len,
> SCM_HASHTABLE_N_ITEMS (table));
>> len = 0;
>> }
>
> With this change, we got lines similar to the following printed
> periodically -
>
> Vacuum weak hash table assert Table=0x9bdb840 len=0 removed=1
> orig_len=2321 n_items=2321

I guess printing a warning is not worse than crashing.  I was unable to
make this table work in a reliable way in 2.0 without rewriting it, so
in 2.2 there's a new implementation with hopefully no bug in this
regard.

Ludovic what do you thing, should we just be sloppy in 2.0 and remove
the assertion?  I don't think it's fixable.  The other option I see is
to close as WONTFIX.

Andy