From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Linas Vepstas Newsgroups: gmane.lisp.guile.bugs Subject: bug#19180: guile bug#19180: vacuum_weak_hash_table error Date: Wed, 22 Jun 2016 16:11:31 -0500 Message-ID: References: <87k322bi46.fsf@gnu.org> <87twgls26t.fsf@pobox.com> Reply-To: linasvepstas@gmail.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=94eb2c03ee4adad8600535e462b9 X-Trace: ger.gmane.org 1466629958 15548 80.91.229.3 (22 Jun 2016 21:12:38 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 22 Jun 2016 21:12:38 +0000 (UTC) Cc: 19180@debbugs.gnu.org, Ludovic =?UTF-8?Q?Court=C3=A8s?= To: Anand Mohanadoss Original-X-From: bug-guile-bounces+guile-bugs=m.gmane.org@gnu.org Wed Jun 22 23:12:30 2016 Return-path: Envelope-to: guile-bugs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1bFpRa-0004eO-7k for guile-bugs@m.gmane.org; Wed, 22 Jun 2016 23:12:18 +0200 Original-Received: from localhost ([::1]:60909 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bFpRZ-00069V-7i for guile-bugs@m.gmane.org; Wed, 22 Jun 2016 17:12:17 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:46176) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bFpRQ-00067T-5z for bug-guile@gnu.org; Wed, 22 Jun 2016 17:12:09 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bFpRK-00081S-QD for bug-guile@gnu.org; Wed, 22 Jun 2016 17:12:07 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:39216) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bFpRK-00081N-Mi for bug-guile@gnu.org; Wed, 22 Jun 2016 17:12:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1bFpRK-0007AT-BA for bug-guile@gnu.org; Wed, 22 Jun 2016 17:12:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Linas Vepstas Original-Sender: "Debbugs-submit" Resent-CC: bug-guile@gnu.org Resent-Date: Wed, 22 Jun 2016 21:12:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 19180 X-GNU-PR-Package: guile X-GNU-PR-Keywords: Original-Received: via spool by 19180-submit@debbugs.gnu.org id=B19180.146662991927544 (code B ref 19180); Wed, 22 Jun 2016 21:12:02 +0000 Original-Received: (at 19180) by debbugs.gnu.org; 22 Jun 2016 21:11:59 +0000 Original-Received: from localhost ([127.0.0.1]:51553 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bFpRH-0007AC-10 for submit@debbugs.gnu.org; Wed, 22 Jun 2016 17:11:59 -0400 Original-Received: from mail-vk0-f48.google.com ([209.85.213.48]:33486) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bFpRE-00079w-Gk for 19180@debbugs.gnu.org; Wed, 22 Jun 2016 17:11:57 -0400 Original-Received: by mail-vk0-f48.google.com with SMTP id d185so79334604vkg.0 for <19180@debbugs.gnu.org>; Wed, 22 Jun 2016 14:11:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:from:date:message-id :subject:to:cc; bh=LRqw5t60gC2j76yI76rWw7Z4uyGe/MsoOzMhn71lTMk=; b=VOcs0+7xEqHYQK964UkIqvOKUoSoyDy3eAyvOhAFkNukQYN8+hrTmtx+gK5IRHN8tG zDlVGIeFHAPPmL07xRk4mBxLsyVq1yTySO9TInbe3OqA1s/kbAb9MHTFB33sV2JtKjoY MKni6pVTUJ+zhVZlineh5BEZdMgaM4wrva03V681NhD3CK8wQHUD31IjrB2+LwQKo/Fy ZVDNitWOWS1xCOOl140on9blIKnGNPlxJPOY6qqqnQY2KSajAuZrcuBrlbk5h3OidK1F VJHNWeSYKetkQ80gbTC67YEw9O7xcmdb6Y+D70gLv0lqn5Mg9wkB7Fc2Fgc3efvi3h4E otYw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :from:date:message-id:subject:to:cc; bh=LRqw5t60gC2j76yI76rWw7Z4uyGe/MsoOzMhn71lTMk=; b=K6jn2T/aTHytJmLFhXmkeRS6QU7md6xxn3VhPR7cPGlkKzLAwNpAN9vd+1k39mP4XA Bj7IqlgAKhB8cVs/FlgAfSEktQ/LFxfOZJuS17aKBMZq0vnryMnlurHGPLPMIxflLpwY J/sUIPMCaqVp8Wi9HhQoi5HnOB/Cv8kradm/hx1wvJLaCQy63X+q2SJa6yL0Gf4hwZq9 pkcZMkOrlrMNiwGpmzAQPmqfXx2w3m8u4P/6zZnZzOsUT1Pqdzi5YsbcyhOp/qZ2Ny1k YI4NHOmFIxRB+cm+RgSwEdgOGTM3L0IOlcr3VrFERsmWDwVtfnSEO9HyMJ38THyn3DCK xvaw== X-Gm-Message-State: ALyK8tKPBBMEGv9JKQ8e4Sco06JOH78LEikNbjrXgDAYn1X0iDWK0P9qVN43FJZpClm43COHuODm8gwgw4qHlA== X-Received: by 10.159.32.79 with SMTP id 73mr13135832uam.29.1466629910876; Wed, 22 Jun 2016 14:11:50 -0700 (PDT) Original-Received: by 10.103.68.153 with HTTP; Wed, 22 Jun 2016 14:11:31 -0700 (PDT) In-Reply-To: X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 X-BeenThere: bug-guile@gnu.org List-Id: "Bug reports for GUILE, GNU's Ubiquitous Extension Language" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-guile-bounces+guile-bugs=m.gmane.org@gnu.org Original-Sender: "bug-guile" Xref: news.gmane.org gmane.lisp.guile.bugs:8140 Archived-At: --94eb2c03ee4adad8600535e462b9 Content-Type: text/plain; charset=UTF-8 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 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 wrote: > >> Hi :) >> >> On Mon 15 Dec 2014 07:36, Anand Mohanadoss 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 >> > > --94eb2c03ee4adad8600535e462b9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Anand, I've been using guile, straight from git for ma= ybe almost 2 years(??) in a semi-harsh environment (lots of threads, lots o= f C++ smob jiggery-pokery, entering and exiting guile, redirecting ports, u= sing fluids at the scheme/c++ boundary, catching and throwing exceptions to= /from C++, interleaving all this with python, too, -- and medium cpu burn o= ver many days/week) and it seems to work fine.=C2=A0 Try it -- fix a tag, r= un system test, I bet it will work for you.=C2=A0 I think Ludo and Andy hav= e done a good job.

The only recent glitch is that the se= tvbuf API changed.=C2=A0 An old quasi-issue is that garbage collection seem= s to not be aggressive enough.=C2=A0 After several layers of C calling guil= e 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 i= t does that in guile-2.0 too.

--linas
<= div class=3D"gmail_extra">
On Wed, Jun 22, 20= 16 at 10:43 AM, Anand Mohanadoss <anand108@gmail.com> wrote= :
Hi Andy= ,

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

Thanks,
Anand<= br>

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 =3D len;
> 137,138c138,144
> < assert (removed <=3D len);
> < len -=3D removed;
> ---
>> if (removed <=3D len)
>> len -=3D removed;
>> else
>> {
>> printf ("Vacuum weak hash table assert Table=3D%p len=3D%zi r= emoved=3D%zi
> orig_len=3D%zi n_items=3D%zi\n", table, len, removed, orig_len, > SCM_HASHTABLE_N_ITEMS (table));
>> len =3D 0;
>> }
>
> With this change, we got lines similar to the following printed
> periodically -
>
> Vacuum weak hash table assert Table=3D0x9bdb840 len=3D0 removed=3D1 > orig_len=3D2321 n_items=3D2321

I guess printing a warning is not worse than crashing.=C2=A0 I was unable t= o
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?=C2=A0 I don't think it's fixable.=C2=A0 The other op= tion I see is
to close as WONTFIX.

Andy


--94eb2c03ee4adad8600535e462b9--