Subj : Re: How to diagnose/resolve libthread panic?
To   : comp.programming.threads
From : roger.faulkner
Date : Thu Jun 09 2005 11:08 pm

> Thanks to all.  I'm trying to apply some of the advice y'all have
> posted so far. It's a big job - as I said, we typically have 277 LWPs
> running.  I have verified that we're using Solaris native threads.  A
> couple of us remember that we had problems using the "alternate
> threads", but don't remember what those problems were.  It was a couple
> of years ago, so maybe the alternate threads were immature?

If you are up-to-date with libthread patches, then your Solaris 8
alternate libthread is identical to the only libthread in Solaris 9.
I can't imagine any problem with you switching to it, unless you
are relying on the particular implementation of the old libthread.
The interfaces are identical but the new libthread is simpler, smaller,
faster, and correct (bugs that are unfixable in the old libthread,
especially bugs related to signals, don't exist in the new).

Once you start using the new (alternate) libthread, you can try out
a not-widely advertized debugging facility.  If you put this into your
environment:

    export LIBTHREAD_ERROR_DETECTION=2

then the new libthread will detect certain programming violations, like
attempts to lock the same (non-recursive) mutex twice in the same
thread,
using a recursive mutex (locked more than once) in a call to
pthread_cond_wait(),
etc., and when it detects such a violation it will dump core with an
explanatory
error message written to stderr.  If you set the environment variable
to 1,
it will emit the error message but carry on regardless.

Applying pstack(1) to your core files will show cleaner stack traces
than with
the old libthread.  In the new libthread, there are no daemon threads
spawned
by the library; you only get the threads that you create.

BTW: you never answered my implied question:  Do you actually get a
message
of the form: "libthread panic: ..." or do you just get a core dump?  If
the latter,
then it is a 99.9% chance that the problem lies in the application, not
libthread.

Roger Faulkner
Sun Microsystems

.