Skip site navigation (1)Skip section navigation (2)
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>