From owner-freebsd-threads@FreeBSD.ORG Sat Jun 5 12:41:18 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 7670216A4CE; Sat, 5 Jun 2004 12:41:18 -0700 (PDT) Received: from ns1.xcllnt.net (209-128-86-226.BAYAREA.NET [209.128.86.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id 16EF943D31; Sat, 5 Jun 2004 12:41:18 -0700 (PDT) (envelope-from marcel@xcllnt.net) Received: from dhcp50.pn.xcllnt.net (dhcp50.pn.xcllnt.net [192.168.4.250]) by ns1.xcllnt.net (8.12.11/8.12.11) with ESMTP id i55JfIpv001279; Sat, 5 Jun 2004 12:41:18 -0700 (PDT) (envelope-from marcel@piii.pn.xcllnt.net) Received: from dhcp50.pn.xcllnt.net (localhost [127.0.0.1]) i55JfEst026872; Sat, 5 Jun 2004 12:41:14 -0700 (PDT) (envelope-from marcel@dhcp50.pn.xcllnt.net) Received: (from marcel@localhost) by dhcp50.pn.xcllnt.net (8.12.11/8.12.11/Submit) id i55JfDal026871; Sat, 5 Jun 2004 12:41:13 -0700 (PDT) (envelope-from marcel) Date: Sat, 5 Jun 2004 12:41:13 -0700 From: Marcel Moolenaar To: Daniel Eischen Message-ID: <20040605194113.GA26707@dhcp50.pn.xcllnt.net> References: <1086458607.18813.37.camel@server.mcneil.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i cc: Sean McNeil cc: freebsd-amd64@freebsd.org cc: freebsd-threads@freebsd.org Subject: Re: All my amd64 problems appear to be KSE 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: Sat, 05 Jun 2004 19:41:18 -0000 On Sat, Jun 05, 2004 at 03:21:29PM -0400, Daniel Eischen wrote: > > > > I suppose it is really libreadline at fault here and it should check > > SA_SIGINFO. Do you think there might be others that don't check either? > > I don't know; perhaps. > > > Why doesn't this show an issue in i386? Is it just luck that info has > > been null and not caused a bad dereference? > > When I write signal handlers, I usually check info and ucp to > make sure they are not null before using them. Actually, I > rarely use them anyways so it doesn't matter if they are null > or not. Nevertheless, libpthread has a signal handler that takes 3 arguments and it apparently gets called from other signal handlers (chaining) that do not always pass along the full context; just the signal number in this case. Consequently, info and ucp can be garbage as is the case here. This is a general problem and potentionally causes failures on all platforms, not just amd64. I tend to give blame to libreadline here, but I don't have a clear or even complete picture of it all, so I might actually miss a vital precondition that's being violated and that would clear libreadline... -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net