From owner-freebsd-current@FreeBSD.ORG Fri Mar 26 13:20:05 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 0F47F16A4D8 for ; Fri, 26 Mar 2004 13:20:05 -0800 (PST) Received: from gw.celabo.org (gw.celabo.org [208.42.49.153]) by mx1.FreeBSD.org (Postfix) with ESMTP id BCFD843D39 for ; Fri, 26 Mar 2004 13:20:04 -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" (verified OK)) by gw.celabo.org (Postfix) with ESMTP id 642CF5487E; Fri, 26 Mar 2004 15:20:04 -0600 (CST) Received: by madman.celabo.org (Postfix, from userid 1001) id EF5BC6D455; Fri, 26 Mar 2004 15:20:03 -0600 (CST) Date: Fri, 26 Mar 2004 15:20:03 -0600 From: "Jacques A. Vidrine" To: Sean McNeil Message-ID: <20040326212003.GE98863@madman.celabo.org> Mail-Followup-To: "Jacques A. Vidrine" , Sean McNeil , freebsd-current@freebsd.org References: <1080273717.18231.10.camel@server.mcneil.com> <20040326125934.GA68357@madman.celabo.org> <1080333620.9866.4.camel@server.mcneil.com> <1080273717.18231.10.camel@server.mcneil.com> <20040326125934.GA68357@madman.celabo.org> <1080334840.11426.12.camel@server.mcneil.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1080333620.9866.4.camel@server.mcneil.com> <1080334840.11426.12.camel@server.mcneil.com> X-Url: http://www.celabo.org/ User-Agent: Mutt/1.5.6i cc: freebsd-current@freebsd.org 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: Fri, 26 Mar 2004 21:20:05 -0000 On Fri, Mar 26, 2004 at 12:40:20PM -0800, Sean McNeil wrote: > Interesting!!! Not what I had thought was going on. I compiled libc > with symbols and I get this: > > #0 0x28214800 in ?? () > #1 0x2816be35 in nss_atexit () at > /usr/src/lib/libc/net/nsdispatch.c:518 > #2 0x2818e9db in __cxa_finalize (dso=0x0) > at /usr/src/lib/libc/stdlib/atexit.c:184 > #3 0x2818e6fc in exit (status=672827136) at > /usr/src/lib/libc/stdlib/exit.c:69 > #4 0x08049b68 in free () at /usr/src/lib/libc/stdlib/malloc.c:1153 > #5 0x08049279 in free () at /usr/src/lib/libc/stdlib/malloc.c:1153 > > So even though the write lock didn't cause a crash the unlock did. That's quite curious! It makes me suspect that somewhere in one of ns_dbt_free or ns_mod_free, the lock is getting trashed. On Fri, Mar 26, 2004 at 01:00:40PM -0800, Sean McNeil wrote: > This appears to be an issue with any external nss_*.so.1 module that > uses pthread. Hmm, perhaps so. One thing that is happening between the wrlock and unlock that we're looking at, is that NSS modules will be dlclosed(), and thus all libraries in the dependency DAG will also be unloaded. > It looks to me it is about the following: > > /* > * Cleanup > */ > static void > nss_atexit(void) > { > (void)_pthread_rwlock_wrlock(&nss_lock); > VECTOR_FREE(_nsmap, &_nsmapsize, sizeof(*_nsmap), > (vector_free_elem)ns_dbt_free); > VECTOR_FREE(_nsmod, &_nsmodsize, sizeof(*_nsmod), > (vector_free_elem)ns_mod_free); > (void)_pthread_rwlock_unlock(&nss_lock); > } > > In my case, the nss_ldap.so.1 module was loaded which pulls in > libpthread. Hmm, but RTLD_LOCAL is being used here, so symbols in nss_ldap.so.1's dependency DAG shouldn't become visible for the rest of the processes objects... hmm > I'm not sure how this works without a libpthred, but it > would appear that unless libpthread.so is loaded everything is OK. But > now, it has been loaded and the rwlock_wrlock() works, but then it has > been unloaded before rwlock_unlock() gets called. > > Would using > > #include > rwlock_wrlock() > rwlock_unlock() > > macros fix this? AFAIK, those macros are only an optimization--- they just check a global variable to see if we're threaded or not. Good detective work. I must split for now, but maybe some RTLD and thread gurus could glance at what we're discussing here and let us know if anything smells funny... Certainly, I would not be surprised if there are side effects I have not calculated due to loading/unloading libpthread... Cheers, -- Jacques Vidrine / nectar@celabo.org / jvidrine@verio.net / nectar@freebsd.org