nss_ldap broken
Sean McNeil
sean at mcneil.com
Fri Mar 26 11:46:49 PST 2004
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.
More information about the freebsd-current
mailing list