bug#19180: guile bug#19180: vacuum_weak_hash_table error

[Linas Vepstas <linasvepstas@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 2394 bytes --]

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 <anand108@gmail.com>
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 <wingo@pobox.com> wrote:
>
>> Hi :)
>>
>> On Mon 15 Dec 2014 07:36, Anand Mohanadoss <anand108@gmail.com> 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
>>
>
>

[-- Attachment #2: Type: text/html, Size: 3428 bytes --]