Date: Sat, 05 Jun 2004 10:16:08 -0700 From: Sean McNeil <sean@mcneil.com> To: Daniel Eischen <eischen@vigrid.com> Cc: freebsd-threads@freebsd.org Subject: Re: All my amd64 problems appear to be KSE Message-ID: <1086455768.18813.12.camel@server.mcneil.com> In-Reply-To: <Pine.GSO.4.10.10406051258210.14185-100000@pcnet5.pcnet.com> References: <Pine.GSO.4.10.10406051258210.14185-100000@pcnet5.pcnet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <signal handler called>
You will see that libreadline invokes the handler as:
202 (*oh) (sig);
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1086455768.18813.12.camel>