From owner-freebsd-current@FreeBSD.ORG Thu Apr 1 06:36:29 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B6F0A16A4CE for ; Thu, 1 Apr 2004 06:36:29 -0800 (PST) Received: from gw.celabo.org (gw.celabo.org [208.42.49.153]) by mx1.FreeBSD.org (Postfix) with ESMTP id 73A8B43D31 for ; Thu, 1 Apr 2004 06:36:29 -0800 (PST) (envelope-from nectar@celabo.org) Received: from madman.celabo.org (madman.celabo.org [10.0.1.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "madman.celabo.org", Issuer "celabo.org CA" (not verified)) by gw.celabo.org (Postfix) with ESMTP id E201754846; Thu, 1 Apr 2004 08:36:28 -0600 (CST) Received: by madman.celabo.org (Postfix, from userid 1001) id C69DF6D465; Thu, 1 Apr 2004 08:36:27 -0600 (CST) Date: Thu, 1 Apr 2004 08:36:27 -0600 From: "Jacques A. Vidrine" To: Oliver Eikemeier Message-ID: <20040401143627.GA60225@madman.celabo.org> Mail-Followup-To: "Jacques A. Vidrine" , Oliver Eikemeier , Daniel Eischen , Sean McNeil , freebsd-current@FreeBSD.org References: <406C217A.8080102@fillmore-labs.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <406C217A.8080102@fillmore-labs.com> X-Url: http://www.celabo.org/ User-Agent: Mutt/1.5.6i cc: freebsd-current@FreeBSD.org cc: Sean McNeil Subject: Re: nss_ldap broken X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Apr 2004 14:36:29 -0000 On Thu, Apr 01, 2004 at 04:04:42PM +0200, Oliver Eikemeier wrote: > Daniel Eischen wrote: > > >On Thu, 1 Apr 2004, Oliver Eikemeier wrote: > [...] > >>- it should be documented somewhere (bsd.port.mk gives you only > >>PTHREAD_LIBS) > > As far as I understand the problem, every application that doesn't link to > pthreads, but uses a library that does crashes on -CURRENT. Am I right > there? No. Problems only occur if run-time loading/unloading via dlopen/dlclose is used, and then only if a lock or other thread library data structure might be held ``across'' the load or unload. So I think it is a rare, but troublesome, condition. When you changed the way OpenLDAP was linked, this condition occurred within libc due to dynamic loading of nss_ldap. So, lots of people's working systems suddenly starting crashing after upgrading. I was able to work around the problem in libc, because there, we have the freedom to putz with internals like __isthreaded. Real applications don't have that luxury. [...] > >I think it is dependent on the library. If the library truly is > >creating threads behind the scene (suppose there were a libaio) > >then it needs the threads library. > > > >On the other hand, for applications that want to use libaio, you > >could force them to link to a threads library instead of having > >it automatically brought in by libaio. > > I guess the latter approach will be preferrable, especially since the > former does seem to trigger the problem we have... So far no library has been found that does ``the former'' (create threads behind the scene). It seems to me we need one of a few things to happen to our threads implementation*s*: (a) pthread.h provides all the magic needed to make pthread_* symbols weak, i.e. transparently providing the functionality of the `libgcc hack' which Dan says would avoid the problem. (b) ``somehow'' arrange for the unloading of a thread library to fixup the pthread stubs `back to normal'. er, that sounds like a load of work and dangerous to boot. (c) teach rtld to treat thread libraries specially: ignore them during dlopen even if they are specified in DT_NEEDED. perhaps we could add some info to the ELF headers of our thread libraries that rtld could use to implement this. hacky. Cheers, -- Jacques Vidrine / nectar@celabo.org / jvidrine@verio.net / nectar@freebsd.org