From owner-freebsd-threads@FreeBSD.ORG Mon Sep 17 04:35:34 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 46C2A16A419; Mon, 17 Sep 2007 04:35:34 +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 027D013C46A; Mon, 17 Sep 2007 04:35:31 +0000 (UTC) (envelope-from lavajoe@gentoo.org) Received: from [67.40.138.82] (crater.wildlava.net [67.40.138.82]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by shadow.wildlava.net (Postfix) with ESMTP id 1F5188F424; Sun, 16 Sep 2007 22:35:31 -0600 (MDT) Message-ID: <46EE0412.70206@gentoo.org> Date: Sun, 16 Sep 2007 22:35:30 -0600 From: Joe Peterson User-Agent: Thunderbird 2.0.0.6 (X11/20070822) MIME-Version: 1.0 To: Jason Evans References: <46E9CBC8.3060906@gentoo.org> <46E9E867.7030909@freebsd.org> <46EAEABA.20003@gentoo.org> <46EB152B.1080905@freebsd.org> In-Reply-To: <46EB152B.1080905@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1 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: Mon, 17 Sep 2007 04:35:34 -0000 Jason Evans wrote: > 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). This would indeed explain the issue. It is as if some symbols come from libthr and some from libpthread. Or maybe sometimes the libthr version gets called and other timed the libpthread. For now, I am symlinking libpthread.so and libc_r.so to libthr.so (and same for the .a files), and this seems to fix the issue. These are the same libs that we map in libmap.conf. If you remember more about this let me know, or if anyone else knows more about this potential issue, I'd love to hear more! Thanks, Joe