From owner-freebsd-threads@FreeBSD.ORG Fri Sep 14 23:22:43 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 8E5A216A419 for ; Fri, 14 Sep 2007 23:22:43 +0000 (UTC) (envelope-from lavajoe@gentoo.org) Received: from shadow.wildlava.net (shadow.wildlava.net [67.40.138.81]) by mx1.freebsd.org (Postfix) with ESMTP id 3399613C461 for ; Fri, 14 Sep 2007 23:22:43 +0000 (UTC) (envelope-from lavajoe@gentoo.org) Received: from [10.1.2.161] (pawnee.wildlava.net [67.40.138.85]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by shadow.wildlava.net (Postfix) with ESMTP id 4BE528F436; Fri, 14 Sep 2007 17:22:42 -0600 (MDT) Message-ID: <46EB17B0.2060507@gentoo.org> Date: Fri, 14 Sep 2007 17:22:24 -0600 From: Joe Peterson User-Agent: Thunderbird 2.0.0.6 (X11/20070816) MIME-Version: 1.0 To: Ivan Voras References: <46E9CBC8.3060906@gentoo.org> <46E9E867.7030909@freebsd.org> <46EAEABA.20003@gentoo.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: 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:22:43 -0000 Ivan Voras wrote: > Joe Peterson wrote: > >> 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. > > Hmmm, maybe static linkage of libpthread? But why would anyone do such a > thing? Yeah, that would be strange. But when I move libpthread.so out of the way, the crash stops happening, so I assume it's dynamically referencing it. Strangely, it doesn't complain when I move it, so it's as if something is grabbing libpthread.so if it's there but falling back to something else (I assume libthr.so) if not. Here's the output of ldd /usr/bin/mogrify: /usr/bin/mogrify: libMagick.so.10 => /usr/lib/libMagick.so.10 (0x28086000) libWand.so.10 => /usr/lib/libWand.so.10 (0x2826c000) libtiff.so.3 => /usr/lib/libtiff.so.3 (0x2832b000) libjpeg.so.62 => /usr/lib/libjpeg.so.62 (0x2837f000) libfontconfig.so.1 => /usr/lib/libfontconfig.so.1 (0x2839e000) libxml2.so.2 => /usr/lib/libxml2.so.2 (0x283c9000) libpthread.so.2 => /usr/lib/libthr.so.2 (0x284eb000) libiconv.so.2 => /lib/libiconv.so.2 (0x284fd000) libXext.so.6 => /usr/lib/libXext.so.6 (0x285db000) libXt.so.6 => /usr/lib/libXt.so.6 (0x285e9000) libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0x28638000) libz.so.1 => /lib/libz.so.1 (0x286b3000) libSM.so.6 => /usr/lib/libSM.so.6 (0x286c5000) libICE.so.6 => /usr/lib/libICE.so.6 (0x286ce000) libX11.so.6 => /usr/lib/libX11.so.6 (0x286e5000) libXau.so.6 => /usr/lib/libXau.so.6 (0x287d0000) libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0x287d3000) librpcsvc.so.3 => /usr/lib/librpcsvc.so.3 (0x287d8000) libm.so.4 => /lib/libm.so.4 (0x287e0000) libc.so.6 => /lib/libc.so.6 (0x287f6000) libgcc_s.so.1 => /usr/lib/gcc/i686-gentoo-freebsd6.2/4.2.0/libgcc_s.so.1 (0x288e0000) Note that the only reference to threads is the redirection from libmap.conf of libpthread -> libthr... So I cannot see how anything would pick up the real libpthread. -Joe