From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: michaelawells Newsgroups: gmane.lisp.guile.bugs Subject: Re: possible gc/weak hash table bug Date: Fri, 25 Mar 2011 20:15:30 -0500 Message-ID: References: NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-9-672383661 X-Trace: dough.gmane.org 1301102163 518 80.91.229.12 (26 Mar 2011 01:16:03 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sat, 26 Mar 2011 01:16:03 +0000 (UTC) To: Andy Wingo , bug-guile@gnu.org Original-X-From: bug-guile-bounces+guile-bugs=m.gmane.org@gnu.org Sat Mar 26 02:15:48 2011 Return-path: Envelope-to: guile-bugs@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Q3I6W-0004Ix-1G for guile-bugs@m.gmane.org; Sat, 26 Mar 2011 02:15:48 +0100 Original-Received: from localhost ([127.0.0.1]:45177 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Q3I6V-0006rl-Fg for guile-bugs@m.gmane.org; Fri, 25 Mar 2011 21:15:47 -0400 Original-Received: from [140.186.70.92] (port=38345 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Q3I6O-0006oH-8w for bug-guile@gnu.org; Fri, 25 Mar 2011 21:15:41 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Q3I6M-0001W1-Rr for bug-guile@gnu.org; Fri, 25 Mar 2011 21:15:40 -0400 Original-Received: from mail-yi0-f41.google.com ([209.85.218.41]:54552) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Q3I6M-0001Vv-K1 for bug-guile@gnu.org; Fri, 25 Mar 2011 21:15:38 -0400 Original-Received: by yib18 with SMTP id 18so501146yib.0 for ; Fri, 25 Mar 2011 18:15:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:from:mime-version:content-type:subject:date :in-reply-to:to:references:message-id:x-mailer; bh=HreTfCwHTwXdANSYWkkoVk6I0NVZEzfK2ZbGc6Ao4dk=; b=Hzw+g+L0iIrcNgtg2zl15uYQnlUekDPR2uB9VUmdLGpJIwckaP3kSMwziN+ZgBbe8R AdYfsib1qGRkYC6dZw/KUR/qCBGoGp7zg1pyW6EAgq8kSWpB6VnCWqmBpKb/vu2hkc1f mXamksANhNoq72TSA1625vLwVh4RLY3vy29TI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:mime-version:content-type:subject:date:in-reply-to:to :references:message-id:x-mailer; b=WJEuxijIvM8b0lawPvZ9RwC5HZeeNwnsuWURoVJQ4JXFFKQH21evfwBaHwEb0qjnr6 F7vF/lJ8XS3m/i7r0dzgcO+hbpOqBcgCdKBQpfJCc2MKp6EKQ4onTvdNgoge15gr8e6I wuX81KrBCmGbuYOkNk2D4xy0jg3BYdSTjTtgQ= Original-Received: by 10.236.198.81 with SMTP id u57mr1773783yhn.370.1301102138156; Fri, 25 Mar 2011 18:15:38 -0700 (PDT) Original-Received: from [192.168.2.102] (adsl-99-11-51-29.dsl.chcgil.sbcglobal.net [99.11.51.29]) by mx.google.com with ESMTPS id 8sm799074yhx.8.2011.03.25.18.15.34 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 25 Mar 2011 18:15:37 -0700 (PDT) In-Reply-To: X-Mailer: Apple Mail (2.1084) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) X-Received-From: 209.85.218.41 X-BeenThere: bug-guile@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Bug reports for GUILE, GNU's Ubiquitous Extension Language" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: bug-guile-bounces+guile-bugs=m.gmane.org@gnu.org Errors-To: bug-guile-bounces+guile-bugs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.bugs:5376 Archived-At: --Apple-Mail-9-672383661 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 I rebuilt the gc-7.1 library, this time using the = "--enable-threads=3Dposix" configure option. The exact same library was = built. It would appear that configure, at least on my target, enables = threads by default. On Mar 25, 2011, at 4:48 PM, michaelawells wrote: >> On Fri 18 Mar 2011 12:51, address@hidden (Ludovic Court=C3s) writes: >>=20 >> > michaelawells writes: >> > >> >>> size_t len =3D SCM_HASHTABLE_N_ITEMS (table); >> >>>=20 >> >>> while (k--) >> >>> { >> >>> size_t removed; >> >>> SCM alist =3D SCM_SIMPLE_VECTOR_REF (buckets, k); >> >>> alist =3D scm_fixup_weak_alist (alist, &removed); <<<**** = FAILS HERE >> >>> assert (removed <=3D len); >> > >> > Andy, isn=E2t this assertion bogus since N_ITEMS is updated lazily = and >> > thus may not correspond to the current number of items? >>=20 >> I don't think so; this is the procedure that is doing that lazy = sweep. >>=20 >> 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". >=20 > 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. =20 >=20 > 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=3Dposix" = 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.) >=20 > 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.) >=20 > Thanks, >=20 > Michael Wells >=20 --Apple-Mail-9-672383661 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 I = rebuilt the gc-7.1 library, this time using the "--enable-threads=3Dposix"= configure option.  The exact same library was built.  It = would appear that configure, at least on my target, enables threads by = default.

On Mar 25, 2011, at 4:48 PM, michaelawells = wrote:

On Fri 18 Mar 2011 12:51, address@hidden (Ludovic Court=C3s)=
 writes:

> michaelawells <address@hidden> writes:
>
>>>   size_t len =3D SCM_HASHTABLE_N_ITEMS (table);
>>> 
>>>   while (k--)
>>>     {
>>>       size_t removed;
>>>       SCM alist =3D SCM_SIMPLE_VECTOR_REF (buckets, =
k);
>>>       alist =3D scm_fixup_weak_alist (alist, =
&removed);  <<<**** FAILS HERE
>>>       assert (removed <=3D len);
>
> Andy, isn=E2t 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=3Dposix" 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


= --Apple-Mail-9-672383661--