From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Daniel Hartwig Newsgroups: gmane.lisp.guile.devel Subject: Re: The 2.0.9 VM cores in enqueue (threads.c:309) Date: Mon, 29 Apr 2013 17:16:32 +0800 Message-ID: References: <517C2DBF.7050304@computer.org> <517E1990.3090302@computer.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1367226997 1044 80.91.229.3 (29 Apr 2013 09:16:37 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 29 Apr 2013 09:16:37 +0000 (UTC) Cc: guile-devel@gnu.org To: Andrew Gaylard Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Mon Apr 29 11:16:42 2013 Return-path: Envelope-to: guile-devel@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 1UWkCP-0004mZ-NZ for guile-devel@m.gmane.org; Mon, 29 Apr 2013 11:16:41 +0200 Original-Received: from localhost ([::1]:60938 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UWkCP-00042u-4E for guile-devel@m.gmane.org; Mon, 29 Apr 2013 05:16:41 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:38328) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UWkCM-00042m-8Z for guile-devel@gnu.org; Mon, 29 Apr 2013 05:16:39 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UWkCH-0004lC-Bl for guile-devel@gnu.org; Mon, 29 Apr 2013 05:16:38 -0400 Original-Received: from mail-ia0-x234.google.com ([2607:f8b0:4001:c02::234]:45890) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UWkCH-0004l0-7h for guile-devel@gnu.org; Mon, 29 Apr 2013 05:16:33 -0400 Original-Received: by mail-ia0-f180.google.com with SMTP id t4so4455851iag.11 for ; Mon, 29 Apr 2013 02:16:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=4Ir9zVmzknjdFAdTEucTmVHkwDahLuvkO5ZQhXJsxOM=; b=LZMnrKTUF7aPSv6NZylxJdx0q22DESxf3dNX1BubZGggN0RGwWjTuAhurqDqHb6Gs7 vZQtsTce8zQZWWwFAzMPrTWIpyIzoLJEbO4om0Av6umoduydeCGcUmFC5sVuyvPfaE+q P1RlJNhabzpCK1gVTCzIBFbJB33ZB4mjjwnUKOSMcEt9L74fi6tB8nzore9D/W/b5F/9 heB6+sPYLc/HvyjBIpXrGaz7xg6ezhzvkwHSmcX2yfX5JUSrWBzUL5QID5pkR44xnR7I O3JKEUAYCW5+/qPGxXyxlvPnhIUiu0pApHTVpMGHd324zOMu2+o2ATJpe7+SRTcJPU2Z 8WXw== X-Received: by 10.42.48.7 with SMTP id q7mr636021icf.35.1367226992429; Mon, 29 Apr 2013 02:16:32 -0700 (PDT) Original-Received: by 10.64.103.196 with HTTP; Mon, 29 Apr 2013 02:16:32 -0700 (PDT) In-Reply-To: <517E1990.3090302@computer.org> X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2607:f8b0:4001:c02::234 X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Developers list for Guile, the GNU extensibility library" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Original-Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.devel:16308 Archived-At: On 29 April 2013 14:56, Andrew Gaylard wrote: > On 04/28/13 03:07, Daniel Hartwig wrote: >> >> On 28 April 2013 03:57, Andrew Gaylard wrote: >>> >>> Those 0x304 values look dodgy to me, and explain why the >>> SCM_SETCDR causes an invalid memory access. >>> >> 0x304 is SCM_EOL. > > Hi Daniel, > > Thanks for the feedback. > > Are you saying that the 0x304 values are fine, and the problem lies > elsewhere? > (e.g. heap corruption, ...) Yes and no. They are fine in the sense that it is a valid SCM value, and expected in some situations. I wanted to investigate the specific code before commenting further. Certainly it should never be the subject of =E2=80=98SCM_SETCDR=E2=80=99. The value of C at that point: > (gdb) p *SCM2PTR(c) > $28 =3D {word_0 =3D 0x1018aac20, word_1 =3D 0x304} is as expected, a one-element list. Q however: > (gdb) p *SCM2PTR(q) > $26 =3D {word_0 =3D 0x304, word_1 =3D 0x1039c4c20} should not occur according to my reading of the three queue procedures in threads.c. The car (word_0) is the final pair in the queue and should only be =E2=80=98()=E2=80=99 (or 0x304) when the cdr is also. Only = two lines that could assign this value, and both appear fine unless one of the conditions is failing somehow. For the moment I have no more idea. I briefly suspected the initialization of =E2=80=98prev =3D q=E2=80=99 in =E2=80=98remqueue=E2=80= =99 being outside the critical section, but as Q itself never changes that can be dismissed. So needs more looking at, maybe there is some other code that modifies these queues. Regards