SMP hard lock with libpthread (thread X holds Y but isn'tblocked on a lock)

Doug White dwhite at gumbysoft.com
Wed May 18 15:15:00 PDT 2005


On Tue, 17 May 2005, Kris Kennaway wrote:

> On Tue, May 17, 2005 at 08:26:11AM -0700, othermark wrote:
> > Kris Kennaway wrote:
> >
> > > On Mon, May 16, 2005 at 08:33:14AM -0700, othermark wrote:
> > >> I have an application that uses shared memory/threads and is linked with
> > >> libpthread, running on May 10 -current.  Every time I run it, after a few
> > >> minutes *poof* hard lock on a SMP box.  All debug options are enabled in
> > >> the kernel, but it won't break to debugger.  Here's what appears on the
> > >> console, and addr2line output follows:
> > >
> > > Try the NMI debugger patches, which might be sufficient to get it into
> > > DDB.
> > >
> > > Kris
> >
> > Jonathan's report on this issue, does have the stack trace, but seems to
> > be triggered by nfs.
> >
> > http://article.gmane.org/gmane.os.freebsd.current/69268
>
> The 'turnstile' panic may be secondary, and the real panic was in some
> other thread.  That's why you'd need to get into DDB.

Someone else posted a full trace; it looks like a locking problem in
nfs_sigmask().

> > However, simply recompiling my application with libthr instead of libpthread
> > completely avoids the panic.
>
> Obviously not a real solution..



>
> Kris
>

-- 
Doug White                    |  FreeBSD: The Power to Serve
dwhite at gumbysoft.com          |  www.FreeBSD.org


More information about the freebsd-current mailing list