From owner-freebsd-threads@FreeBSD.ORG Fri Sep 14 23:29:35 2007 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4615016A417; Fri, 14 Sep 2007 23:29:35 +0000 (UTC) (envelope-from jasone@freebsd.org) Received: from canonware.com (canonware.com [64.183.146.166]) by mx1.freebsd.org (Postfix) with ESMTP id 1D0EE13C45E; Fri, 14 Sep 2007 23:29:34 +0000 (UTC) (envelope-from jasone@freebsd.org) Received: from [192.168.168.201] (canonware.com [64.183.146.166]) by canonware.com (Postfix) with ESMTP id 6EB3F129821; Fri, 14 Sep 2007 16:17:24 -0700 (PDT) Message-ID: <46EB152B.1080905@freebsd.org> Date: Fri, 14 Sep 2007 16:11:39 -0700 From: Jason Evans User-Agent: Thunderbird 1.5.0.12 (X11/20070718) MIME-Version: 1.0 To: Joe Peterson References: <46E9CBC8.3060906@gentoo.org> <46E9E867.7030909@freebsd.org> <46EAEABA.20003@gentoo.org> In-Reply-To: <46EAEABA.20003@gentoo.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: David Xu , freebsd-threads@freebsd.org Subject: Re: Segfault when mapping libpthread -> libthr X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Sep 2007 23:29:35 -0000 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