From owner-freebsd-threads@FreeBSD.ORG Sat Jun 5 10:04:39 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 3890B16A4CE; Sat, 5 Jun 2004 10:04:39 -0700 (PDT) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id EAD4B43D3F; Sat, 5 Jun 2004 10:04:38 -0700 (PDT) (envelope-from eischen@vigrid.com) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mail.pcnet.com (8.12.10/8.12.1) with ESMTP id i55H4btD026427; Sat, 5 Jun 2004 13:04:37 -0400 (EDT) Date: Sat, 5 Jun 2004 13:04:37 -0400 (EDT) From: Daniel Eischen X-Sender: eischen@pcnet5.pcnet.com To: Sean McNeil In-Reply-To: <1086453600.96822.16.camel@server.mcneil.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: Tim Robbins 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 17:04:39 -0000 On Sat, 5 Jun 2004, Sean McNeil wrote: > On Sat, 2004-06-05 at 09:31, Tim Robbins wrote: > > > Everything seems to work fine if I build libpthread with SYSTEM_SCOPE_ONLY > > (at least it hasn't crashed so far.) My current guess is that there's a > > bug in context manipulation or signals. I initially thought we weren't > > saving enough FPU context in _amd64_save_context, but adding an fxsave > > in there didn't help. > > I see a problem with bash and signals too when libpthread is involved. > It would core dump when I resize a window. I use nss_ldap and it was > pulling in pthread through db41. I solved my issue by rebuilding db41 > to eliminate pthread from the libdb41.so.1. Perhaps tracing this down > would be useful? Isn't that a known problem? You can't dynamically load libpthread then unload it, which is what nss_ldap was doing. I thought that was fixed so that libpthread wasn't pulled in. It could be possible that something is trying to dlopen() a library that requires libpthread, and libpthread is loaded then unloaded. You can't do that because it'll screw up libc. One way around it is to build all your shared libraries with -pthread which will avoid linking to libpthread (-pthread is a noop when building shared libraries). You should be able to safely set PTHREAD_LIBS to -pthread instead of -lpthread, just keep an eye out for anything that manually brings in -lpthread. -- Dan Eischen