From owner-freebsd-amd64@FreeBSD.ORG Sat Jun 5 10:16:14 2004 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 64F4916A4CE; Sat, 5 Jun 2004 10:16:14 -0700 (PDT) Received: from mail.mcneil.com (rrcs-west-24-199-45-54.biz.rr.com [24.199.45.54]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2C00743D3F; Sat, 5 Jun 2004 10:16:12 -0700 (PDT) (envelope-from sean@mcneil.com) Received: from localhost (localhost.mcneil.com [127.0.0.1]) by mail.mcneil.com (Postfix) with ESMTP id 9A50FFD1D5; Sat, 5 Jun 2004 10:16:09 -0700 (PDT) Received: from mail.mcneil.com ([127.0.0.1]) by localhost (server.mcneil.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 06005-10; Sat, 5 Jun 2004 10:16:09 -0700 (PDT) Received: from [24.199.45.54] (mcneil.com [24.199.45.54]) by mail.mcneil.com (Postfix) with ESMTP id 1E23BFD084; Sat, 5 Jun 2004 10:16:09 -0700 (PDT) From: Sean McNeil To: Daniel Eischen In-Reply-To: References: Content-Type: text/plain Message-Id: <1086455768.18813.12.camel@server.mcneil.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Sat, 05 Jun 2004 10:16:08 -0700 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at mcneil.com 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-amd64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Jun 2004 17:16:14 -0000 On Sat, 2004-06-05 at 10:04, Daniel Eischen wrote: > 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. Yes, this is a known problem. I worked on fixing at least one of the issues with that. The end result is that there is no easy way do handle these cases. That is why I ended up removing pthread from db41. It isn't correct. I felt, though, that the issues with gnome may be related to the bash one as this exact same setup works with i386 and doesn't with amd64. Looking at libreadline now I see there is an error: (gdb) bt #0 _thr_sig_handler (sig=28, info=0x100, ucp=0x201701904) at /usr/src/lib/libpthread/thread/thr_sig.c:373 #1 0x00000002006aea90 in rl_sigwinch_handler (sig=28) at /usr/src/contrib/libreadline/signals.c:202 #2 You will see that libreadline invokes the handler as: 202 (*oh) (sig);