[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#19180: guile bug#19180: vacuum_weak_hash_table error

From: Linas Vepstas
Subject: bug#19180: guile bug#19180: vacuum_weak_hash_table error
Date: Wed, 22 Jun 2016 16:11:31 -0500

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.


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.


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,
>> 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

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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]