kern/86029: undefined reference to `_thread_dump_info'

Daniel Eischen deischen at
Wed Sep 21 12:10:14 PDT 2005

The following reply was made to PR kern/86029; it has been noted by GNATS.

From: Daniel Eischen <deischen at>
To: Christopher Sean Morrison <brlcad at>
Cc: David Xu <davidxu at>, <bug-followup at>
Subject: Re: kern/86029: undefined reference to `_thread_dump_info'
Date: Wed, 21 Sep 2005 15:07:16 -0400 (EDT)

 On Wed, 21 Sep 2005, Christopher Sean Morrison wrote:
 > On Sep 21, 2005, at 1:28 PM, Daniel Eischen wrote:
 > > That's what SIGINFO is for.  Again, that's undocumented and
 > > allowed to change, but it's better than calling a library
 > > internal function.
 > Again, this is really tangent to the whole point of the report, but it
 > does raise ab additional question.  If I raise a SIGINFO, is that going
 > to give identical detail about the current threading states?  I agree
 > that it's better means to the end.  The OpenBSD pthreads(3) manual page
 > does document the signal but I have not had a motivation to change/test
 > that bit of code until now.
 If you're debugging the threads library, you should be looking
 at its source.  SIGINFO just calls _thread_dump_info() (which
 is not exported in libpthread) and does the same thing.  But,
 SIGINFO was meant more for us to debug the thread library.
 > Which has always been my understanding of -pthread as well.  Does this
 > mean then that the C library routines on an AMD64 FreeBSD 5.4 system
 > are supposed to be re-entrant and thread safe?
 Of course.
 > If that's the case,
 > then I probably have another bug report to make.  It also doesn't
 > explain the inconsistency with the same rev of FreeBSD on IA32 systems
 > where the same behavior is not exhibited.
 I'm going to close this one.  You'll need something that
 easily regenerates your problem if you file another bug
 report on it.

More information about the freebsd-threads mailing list