Bug 495701

See here as well:
https://bugzilla.redhat.com/show_bug.cgi?id=314811
http://www.linuxquestions.org/questions/linux-server-73/openldap-assertion-error-ldapparseresult-assertion-r-void-0-failed-705397

I didn't manage to reproduce this bug, I tried several hundred times:

1. Renice slapd to +19
2. Stress the machine (stress --cpu 20 --vm 20 or stress --cpu 10 --vm 10 --io 10 --hdd 10).
3. for i in `seq 1 100`; do getent passwd <user>; echo $i; done

I tried this both on 32 bit system and 64 bit system. I also tried to set smaller values of timeouts in /etc/ldap.conf. In extreme cases getent hang until system was no longer stressed, but not a single crash.

Do you have any more info about this issue? If not, I'm sorry, but I'm going to close this bug as WORKSFORME.

Sorry for this issue. Seems we are quite often having problems noone else has
in the world :-( . Probably due to a relatively large scale and heavily loaded
environment. Sorry i have no more info about this problem. Probably with
a newer openldap release this is gone anyway (?).

Ok, for now I'm closing this bug. Please re-open this issue if problems persist in newer versions of openldap.

We're experiencing this also - Red Hat SR#1930570

while in an NFS mounted directory, I ran "ls -l" and got the following:
ls: ../../../libraries/libldap/error.c:273: ldap_parse_result: Assertion `r != ((void *)0)' failed

Subsequent invocations of "ls -l" ran fine.

Our master OpenLDAP doesn't seem to be taxed much though.

# rpm -qa | grep ldap
nss_ldap-253-17.el5
openldap-2.3.43-3.el5
mozldap-6.0.5-1.el5
python-ldap-2.2.0-2.1
nss_ldap-253-17.el5
openldap-2.3.43-3.el5
[root@ai13-07 /]# uname -a
Linux ourserver 2.6.18-128.1.10.el5 #1 SMP Wed Apr 29 13:53:08 EDT 2009 x86_64 x86_64 x86_64 GNU/Linux
#

This seems to be resolved by increasing the nss_ldap bind_timeout parameter.  I had it at 2 from a RHEL4 environment.  Increasing this to 120, while it may be overkill, resolved the problem.  We'll likely end up reducing this to a comfortable level that does not invoke the error.

Anyway this is a workaround and does not solve the actual problem. The client should try to bind to the next configured server. Having tried all servers, it should issue a warning, probably fail later. When behaving this way, there might be an additional parameter to configure e.g. allservers_fail_timeout.

Since this error seems to live, I'm reopening this bug and will be investigating it.

Created attachment 365239 [details]
Patch fixing this issue

I backported patch from upstream, it should eliminate the issue.

Patch is in CVS, changing status to MODIFIED.

Bug reported in description is not caused by openldap.

It's the nss_ldap bug (see BZ499302). However, this bug was fixed in 5.4.z, so it is not expected to be reproducible unless you downgrade to nss_ldap < 253-22. NFS bug reported in Comment #5 is very probably the same nss_ldap problem. 

Please note that this problem was fixed in nss_ldap itself which is built with static copy of libldap.

It's reasonable to apply proposed patch to openldap, but of course it can't affect nss_ldap now.

Hence I suggest to close this bug with NOTABUG, CURRENTRELEASE or DUPLICATED (BZ499302).

Please see Comment 15 first. 

You should have installed nss_ldap-253-22 to avoid described bugs (getent, nfs). 

Since this bug is not directly caused by openldap, we perform sanity checks only - patched openldap must work correctly without any regression.

Sanity verification successfull on RHEL5.5-{Client,Server}-20100129.nightly.

An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHSA-2010-0198.html