Segfault when mapping libpthread -> libthr

[Jason Evans]

Joe Peterson wrote:
> Update: Upon investigating what code could possibly change %%gs, which
> holds curthread (I am on i386 arch), the only other candidate, of
> course, was libpthread itself, which is mapped to libthr by libmap.conf
> (thereby hopefully causing it to not be used).
> 
> But to test this, I temporarily removed libpthread.so (link) from
> /usr/lib.  This actually made the problem disappear!  So it appears that
> both libthr and libpthread are being used by mogrify or its libs, which
> now would explain the crash.  I assume libpthread grabbed a new thread
> address and updated curthread out from under libthr.
> 
> So the question now (which I am currently investigting) is how could
> this happen?  I have used ldd to examine the binaries and all libs, and
> they all show libpthread mapped to libthr.  I do not know of a way for
> libmap.conf to be bypassed (someone suggested a hard-coded lib
> file/path).  If anyone has ideas, please let me know.  Otherwise I'll
> keep plugging away at this and report the results when I figure it out.

I saw something similar a while back when investigating malloc problem 
reports (that turned out to be a threads problem).  It looked to me like 
there was a minor incompatibility in the exported symbols of libpthread 
and libthr that caused rtld to pull some symbols from libpthread, 
despite the libmap.conf settings.  IIRC, the symbol incompatibilities 
did not at first glance seem like they would cause the problem, but my 
guess (unverified) was that dynamic dependency resolution was chasing a 
dependency into libpthread before a legitimate dependency through libthr 
managed to map the symbol.

I'm sorry that I don't remember the nature of the library interface 
incompatibilities.  It seems to me though that it was pretty subtle, 
having to do with weak internally exported symbols (available to other 
.o's within the library, but not to external consumers of the library).

Jason