Date: Fri, 26 Mar 2004 11:46:43 -0800 From: Sean McNeil <sean@mcneil.com> To: "Jacques A. Vidrine" <nectar@freebsd.org> Cc: freebsd-current@freebsd.org Subject: Re: nss_ldap broken Message-ID: <1080330403.73854.6.camel@server.mcneil.com> In-Reply-To: <20040326125934.GA68357@madman.celabo.org> References: <1080273717.18231.10.camel@server.mcneil.com> <20040326125934.GA68357@madman.celabo.org>
next in thread | previous in thread | raw e-mail | index | archive | help
After looking this over I am fairly confident that it is something outside of libc. This is extremely odd. If I move things to be passwd: ldap files group: ldap file I get less occcurances of seg 11s, but still they happen. It would appear to happen on processes that somehow load the nss_ldap module but never use it. This could happen for the above case because I also have hosts: files dns I will try to rebuild with symbols. Sean On Fri, 2004-03-26 at 04:59, Jacques A. Vidrine wrote: > On Thu, Mar 25, 2004 at 08:01:58PM -0800, Sean McNeil wrote: > > Hi everyone, > > > > I'm getting frustrated trying to figure out what is wrong here. I get > > seg 11 on any program that initializes the nss_ldap module but doesn't > > actually use it. For instance, I have both passwd and group looking at > > "files ldap". So if I do something like > > > > ls -l / > > > > it works with no problem as I have a directory in there with a group > > only in ldap. But if I do > > > > ls -l /etc > > > > I will get a seg11... > > > > #0 0x28214800 in ?? () > > #1 0x2816bdb5 in _nsdbtput () from /lib/libc.so.5 > > #2 0x2818e95b in __cxa_finalize () from /lib/libc.so.5 > > #3 0x2818e67c in exit () from /lib/libc.so.5 > > #4 0x08049b68 in free () > > #5 0x08049279 in free () > > Can you rebuild ls and libc with symbols and mail me the stack trace > from that? > > At first I thought that perhaps something was invoking nsdispatch() in > an atexit handler *after* nss_atexit had run, but even so that would > be more or less safe. > > > I've looked at the nss_atexit and can't see what could possibly be the > > problem. There is only one thing I can think of (just came to mind > > while writing this). The lock nss_lock seems to be kept after > > nss_configure and never released unless a call to dispatch is called > > where it will lock then unlock. Yet this would appear to be the same > > for any of the builtins. > > Hmm, it does seem that there is an error situation where that could > be the case, but the problem description above doesn't follow from > that case. The patch will fix it. (The situation would occur if > /etc/nsswitch.conf existed, but was not readable.) > > > Does anyone have any insight into what this might be? I would love to > > have it working again. > > I will try to reproduce here. So far no luck.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1080330403.73854.6.camel>