From owner-freebsd-threads@FreeBSD.ORG Fri Oct 29 04:52:01 2004 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BC03116A4CE; Fri, 29 Oct 2004 04:52:01 +0000 (GMT) Received: from freebsd3.cimlogic.com.au (adsl-20-121.swiftdsl.com.au [218.214.20.121]) by mx1.FreeBSD.org (Postfix) with ESMTP id DE4C043D46; Fri, 29 Oct 2004 04:52:00 +0000 (GMT) (envelope-from jb@cimlogic.com.au) Received: by freebsd3.cimlogic.com.au (Postfix, from userid 102) id 638226A9BC; Fri, 29 Oct 2004 14:51:59 +1000 (EST) Date: Fri, 29 Oct 2004 14:51:59 +1000 From: John Birrell To: David Xu Message-ID: <20041029045159.GG47792@freebsd3.cimlogic.com.au> References: <200410281554.07222.jhb@FreeBSD.org> <20041028203900.GF47792@freebsd3.cimlogic.com.au> <41818397.8090303@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <41818397.8090303@freebsd.org> User-Agent: Mutt/1.4.2.1i cc: threads@freebsd.org Subject: Re: Infinite loop bug in libc_r on 4.x with condition variables and signals X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Oct 2004 04:52:01 -0000 On Fri, Oct 29, 2004 at 07:41:11AM +0800, David Xu wrote: > It would be nice if you could provide some example code, even if the code > may contains bug, it is still good for me to see how pthread_cancel can > cause SIG 11, because pthread_cancel seems checking everything carefully. (Note that it is pthread_testcancel, not pthread_cancel, and it is libpthread makeing the call, not the application directly) Sorry, there is absolutely no way I can get a simple/example program. The application only does it when it is loaded serving data at about 4 Mb/s. I haven't seen the SIG 11 on any of my test systems and I *have* tried to create test loads. It only happens on the production server serving the real world. 8-( A second instance of the same program, running on the same server, serving a different group of users at a lower bit rate has never had the problem. -- John Birrell