Date: Fri, 14 Sep 2007 14:10:34 -0600 From: Joe Peterson <lavajoe@gentoo.org> To: David Xu <davidxu@freebsd.org> Cc: freebsd-threads@freebsd.org Subject: Re: Segfault when mapping libpthread -> libthr Message-ID: <46EAEABA.20003@gentoo.org> In-Reply-To: <46E9E867.7030909@freebsd.org> References: <46E9CBC8.3060906@gentoo.org> <46E9E867.7030909@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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 >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?46EAEABA.20003>