Segfault when mapping libpthread -> libthr

[Joe Peterson]

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.

					Thanks, Joe


David Xu wrote:
> Joe Peterson wrote:
>> I am a developer on the Gentoo/FreeBSD project.  For those who don't
>> know, this is basically porting the gentoo tools, package installer,
>> init stuff, etc. to FreeBSD (kernel and userland).  I have been
>> investigating a rather challenging crash in libthr with 6.2.  We have
>> libpthread and libc_r mapped to libthr (as I understand this is the
>> default for 7.0).  I doubt, however, that this issue is gentoo-related,
>> since the system is essentially FreeBSD, but I cannot be 100% sure, of
>> course.
>>
>> In particular, ImageMagick's "mogrify" utility is segfaulting.  I have
>> traced this down to the fact that _cur_thread() returns a different
>> address after many mutex locks in pthread (using the libthr library).
>> This causes the mutex linked list in the thread to have zero pointers
>> for first/last, and the crash results.  I have verified with a
>> ImageMagick developer that mogrfiy is using only one thread, so this
>> should never happen.
>>
>> Another clue is that the curthread address seems to change sometime
>> shortly before __error (in libthr/sys/thr_error.c) gets called.
>>
>> I now am not sure how to debug this further.  The address returned by
>> _get_curthread() is close, but slightly higher (by typically 0x100) than
>> the original thread's address.
>>
>> I can reproduce the problem faithfully on two of my systems, so if any
>> of this rings a bell, or if you have any suggestions for things to try
>> on my end, I'd be extremely appreciative!
>>
>> 						-Joe
> you may try revision 1.3 of
> http://www.freebsd.org/cgi/cvsweb.cgi/src/lib/libthr/sys/thr_error.c
> to see if the problem goes away.
> 
> David Xu
>