From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Neil Jerram Newsgroups: gmane.lisp.guile.devel Subject: Re: i guess we're frozen & stuff Date: Mon, 28 Sep 2009 23:42:26 +0100 Message-ID: <87eipqn12l.fsf@ossau.uklinux.net> References: <0489FB6F-567B-4967-9703-1A3D89462A37@raeburn.org> <79F7A852-10ED-46DF-9D41-ED545493E8FE@raeburn.org> <87pr9dpgfw.fsf@gnu.org> <871vlr6l2p.fsf@ossau.uklinux.net> <87k4zi6h3q.fsf@gnu.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=gb2312 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1254177855 29053 80.91.229.12 (28 Sep 2009 22:44:15 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 28 Sep 2009 22:44:15 +0000 (UTC) Cc: Guile Development To: ludo@gnu.org (Ludovic =?iso-8859-1?Q?Court=E8s?=) Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Tue Sep 29 00:44:08 2009 Return-path: Envelope-to: guile-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1MsOwx-0007vQ-Oh for guile-devel@m.gmane.org; Tue, 29 Sep 2009 00:44:08 +0200 Original-Received: from localhost ([127.0.0.1]:52018 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MsOwx-0002xh-6H for guile-devel@m.gmane.org; Mon, 28 Sep 2009 18:44:07 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MsOvb-0002gf-TB for guile-devel@gnu.org; Mon, 28 Sep 2009 18:42:43 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MsOvV-0002ex-0F for guile-devel@gnu.org; Mon, 28 Sep 2009 18:42:41 -0400 Original-Received: from [199.232.76.173] (port=45560 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MsOvU-0002el-Nk for guile-devel@gnu.org; Mon, 28 Sep 2009 18:42:36 -0400 Original-Received: from mail3.uklinux.net ([80.84.72.33]:40881) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MsOvP-00085k-6d; Mon, 28 Sep 2009 18:42:31 -0400 Original-Received: from arudy (host86-147-112-99.range86-147.btcentralplus.com [86.147.112.99]) by mail3.uklinux.net (Postfix) with ESMTP id 3DFB61F6768; Mon, 28 Sep 2009 23:42:28 +0100 (BST) Original-Received: from arudy (arudy [127.0.0.1]) by arudy (Postfix) with ESMTP id AFDB838021; Mon, 28 Sep 2009 23:42:27 +0100 (BST) In-Reply-To: <87k4zi6h3q.fsf@gnu.org> ("Ludovic =?iso-8859-1?Q?Court=E8s?= =?iso-8859-1?Q?=22's?= message of "Mon, 28 Sep 2009 20:48:09 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.4-2.6 X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Developers list for Guile, the GNU extensibility library" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.devel:9415 Archived-At: ludo@gnu.org (Ludovic Court=A8=A8s) writes: > Hi, > > Neil Jerram writes: > >> ludo@gnu.org (Ludovic Court=A8=A8s) writes: > >>> This must be related to http://savannah.gnu.org/bugs/?27457 . >>> Contributions welcome! ;-) >> >> I will start looking at this later this evening. (Unless you're already >> investigating - in which case please let me know!) > > I won=A1=AFt look into it in the next days, so go ahead! ;-) Well... I don't see the throw from critical section problem. Instead, after a while, I see a hang, with one thread doing: #0 0xb7f06424 in __kernel_vsyscall () #1 0xb7acd255 in sem_wait@@GLIBC_2.1 () from /lib/i686/cmov/libpthread.so.0 #2 0xb7dc2018 in GC_stop_world () from /usr/lib/libgc.so.1 and all the others: #0 0xb7f06424 in __kernel_vsyscall () #1 0xb7b05837 in sigsuspend () from /lib/i686/cmov/libc.so.6 #2 0xb7dc222b in GC_suspend_handler_inner () from /usr/lib/libgc.so.1 #3 0xb7dc22b5 in GC_suspend_handler () from /usr/lib/libgc.so.1 #4 In theory, each other thread must have called sem_post(), and the number of those sem_post()s should be the same as the number of times that the GC_stop_world thread calls sem_wait(), and so the GC_stop_world thread shouldn't be waiting. I wonder if there's a way that the pthread_kill(p->id, SIG_SUSPEND) in GC_stop_world can appear to succeed (by returning 0), but the signalled thread doesn't get the signal, or dies before it does the sem_post()? Regarding the throw from critical section problem, I guess I'm not seeing this because of not running on a multi-core machine. Can someone who does see this problem - run under GDB - set a breakpoint on the fprintf (stderr, "throw from within critical section.\n") line in throw.c - post the thread backtraces (thread apply all bt), when this breakpoint is hit? Thanks. Neil