All my amd64 problems appear to be KSE

[Sean McNeil]

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);