From owner-freebsd-threads@FreeBSD.ORG Sun Jun 6 17:44:13 2004 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 92D1316A4CE; Sun, 6 Jun 2004 17:44:13 -0700 (PDT) Received: from mail.mcneil.com (rrcs-west-24-199-45-54.biz.rr.com [24.199.45.54]) by mx1.FreeBSD.org (Postfix) with ESMTP id 689A543D48; Sun, 6 Jun 2004 17:44:13 -0700 (PDT) (envelope-from sean@mcneil.com) Received: from localhost (localhost.mcneil.com [127.0.0.1]) by mail.mcneil.com (Postfix) with ESMTP id CB594FD020; Sun, 6 Jun 2004 17:44:12 -0700 (PDT) Received: from mail.mcneil.com ([127.0.0.1]) by localhost (server.mcneil.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 00678-03; Sun, 6 Jun 2004 17:44:12 -0700 (PDT) Received: from [24.199.45.54] (mcneil.com [24.199.45.54]) by mail.mcneil.com (Postfix) with ESMTP id 9A0D3FD01A; Sun, 6 Jun 2004 17:44:11 -0700 (PDT) From: Sean McNeil To: Daniel Eischen In-Reply-To: References: Content-Type: text/plain Message-Id: <1086569050.66929.2.camel@server.mcneil.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Sun, 06 Jun 2004 17:44:11 -0700 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at mcneil.com cc: freebsd-amd64@freebsd.org cc: freebsd-threads@freebsd.org Subject: Re: more symbol binding problems X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2004 00:44:13 -0000 On Sun, 2004-06-06 at 17:25, Daniel Eischen wrote: > On Sun, 6 Jun 2004, Sean McNeil wrote: > > > I have another one that I can't explain. apache2 and libphp4. > > > > The php4 shared library that is pulled into apache2 has the following > > (with pthread mapped to libc_r): > > > > /usr/local/libexec/apache2/libphp4.so: > [ ... ] > > libssl.so.3 => /usr/lib/libssl.so.3 (0x202538000) > > libcrypto.so.3 => /lib/libcrypto.so.3 (0x202672000) > > libpthread.so.1 => /usr/lib/libc_r.so.5 (0x2027c5000) > > libsasl2.so.2 => /usr/local/lib/libsasl2.so.2 (0x2028f0000) > > libc.so.5 => /lib/libc.so.5 (0x20062a000) > > > > When I use the ldap account manager package (lam), it causes the httpd > > process to get stuck in a busy-loop eating 1/2 the cpu as: > > > > (gdb) bt > > #0 0x00000002014fcd4e in select () from /lib/libc.so.5 > > #1 0x0000000200c4532e in ldap_int_select (ld=0x8c8c00, timeout=0x0) > > at os-ip.c:733 > > > > I do not understand why it is calling select in lib.so.5. Shouldn't it > > have called the one in libc_r? With GLOBAL or LOCAL DAG this should > > have been resolved via the weak symbol to __select, no? > > Yes, it shouldn't be using select() from libc; select() should be > resolved to _select() in libc_r (which calls __sys_poll() in libc). > > > The interesting thing here is that if I use libpthread for apache then > > there are no problems. Maybe not all that suprising, though, as there > > is no real difference in the select with libpthread whereas libc_r has a > > much more complex implementation. > > Sounds like the linker isn't doing the right thing. Would you think it is the linker, or rtld? Any ideas where I should start? I was going to look through rtld but I will focus on ld if you think that is where the problem is.