Segfault when mapping libpthread -> libthr

[Joe Peterson]

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.

Nope, still same result.  The call to __error() doesn't happen until
quite a few _get_curthread() calls happen and many mutex's get
locked/unlocked, so I was not optimistic this would fix it.

						-Joe