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