Date: Sat, 05 Jun 2004 10:18:42 -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: <1086455922.18813.15.camel@server.mcneil.com> In-Reply-To: <Pine.GSO.4.10.10406051310350.14185-100000@pcnet5.pcnet.com> References: <Pine.GSO.4.10.10406051310350.14185-100000@pcnet5.pcnet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 2004-06-05 at 10:11, Daniel Eischen wrote: > On Sat, 5 Jun 2004, Sean McNeil wrote: > > > On Sat, 2004-06-05 at 09:40, 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? > > > > resize of bash causes error like this: > > > > #0 _thr_sig_handler (sig=28, info=0x100, ucp=0x201701904) > > at /usr/src/lib/libpthread/thread/thr_sig.c:373 > > #1 0x00000002006ae9b0 in _rl_savestring () from /lib/libreadline.so.4 > > #2 <signal handler called> > > #3 0x0000000200a822ec in read () from /lib/libc.so.5 > > #4 0x00000002006ab113 in rl_getc () from /lib/libreadline.so.4 > > #5 0x00000002006ab0c9 in rl_read_key () from /lib/libreadline.so.4 > > #6 0x00000002006bdeb7 in readline_internal_char () from > > /lib/libreadline.so.4 > > That all looks fine, but bash isn't threaded is it? bash isn't naturally threaded. I rebuilt db41 to its default of linking with pthread. This caused threading to be pulled in. Look again, info and ucp are garbage. It core dumps when it tries to dereference info.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1086455922.18813.15.camel>