Date: Sat, 5 Jun 2004 13:04:37 -0400 (EDT) From: Daniel Eischen <eischen@vigrid.com> To: Sean McNeil <sean@mcneil.com> Cc: freebsd-threads@freebsd.org Subject: Re: All my amd64 problems appear to be KSE Message-ID: <Pine.GSO.4.10.10406051258210.14185-100000@pcnet5.pcnet.com> In-Reply-To: <1086453600.96822.16.camel@server.mcneil.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.10.10406051258210.14185-100000>