Red Hat Bugzilla – Bug 143017
LDAP read causes slapd crash in OpenLDAP
Last modified: 2007-11-30 17:10:56 EST
From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041111 Firefox/1.0 Description of problem: I have OpenLDAP ready to replace NIS and authenticate UNIX and Samba user accounts, but unfortunately the slapd daemon frequently crashes during read operations. The first time I made this happen it was trying to use the directory as an address book from a Microsoft Outlook client. No surprise that everything came tumbling down, but now I can regularly crash slapd from my Linux desktop by using a phpLDAPadmin interface I installed on the LDAP server. The error only seems to occur when I do a search on the Users tree of the directory. This contains user accounts. Similar searches on the Groups tree, which contains about as many objects as Users, does not seem to cause the crash. When I add debugging options in /etc/sysconfig/openldap, I see different sorts of debugging data depending on the level (I chose between 1 and 10, but let me know if you need other data). The last output of each debugging level is different after each crash, so it doesn't look like the error is a consistent one. The most error-like last message I have seen is this one: *** glibc detected *** double free or corruption: 0x09d3a4e0 *** The Release Notes for FC3 say that errors similar to this have to do with the new, more strict glibc. So I tried launching it like this: MALLOC_CHECK_=0 /usr/sbin/slapd -u ldap -h "ldap:///" & But it didn't help the matter. slapd still crashed. Speaking of which, whenever I launch slapd from the command line I get a "Segmentation fault" error on the terminal when the crash happens. Version-Release number of selected component (if applicable): 2.2.13-2 How reproducible: Always Steps to Reproduce: 1. Start the slapd daemon 2. Use a client to perform a big search of the directory, preferable concentrating on the Users tree. 3. Crash! Actual Results: slapd crashes, so if this were a production server none of my users would be able to log in. In theory my pager would vibrate. Expected Results: slapd should run, ignoring minor errors. Additional info: I tried downloading an compiling the latest and greatest OpenLDAP, but had similar issues. However I don't know how well I actually built it (authentication was not functional).
Well, it's been a few months and I thought I'd test again now that FC4 test 1 is out. Unfortunately after some testing it seems that this bug is still present on openldap-2.2.23-4. I tested analogous versions on Ubuntu (a Debian-based distro) without any crashes, so it seems to be Fedora-specific. It was in the midst of a search when the crash happened: SRCH "dc=mclean,dc=harvard,dc=edu" 2 3 0 0 0 filter: (&(objectClass=posixGroup)(gidNumber=520)) attrs: dn description *** glibc detected *** /usr/sbin/slapd: double free or corruption (fasttop): 0x09a680c0 *** I know that Red Hat is working on updating and releasing Netscape's Directory product, and that Novell is in the Linux biz now, so if OpenLDAP is a low priority this is understandable. But it would be nice if Red Hat could elaborate on whether these problems in OpenLDAP are urgent (and will be fixed), or if it is hoping to release something based upon Netscape's product to replace OpenLDAP. I can keep debugging this, and submit loads of data for Bugzilla, but please let me know if this isn't going to be fixed so I don't waste time on it. Regards, Ed
This report targets the FC3 or FC4 products, which have now been EOL'd. Could you please check that it still applies to a current Fedora release, and either update the target product or close it ? Thanks.
Fedora Core 3 and Fedora Core 4 are no longer supported. If you could retest this issue on a current release or on the latest development / test version, we would appreciate that. Otherwise, this bug will be marked as CANTFIX one month from now. Thanks for your help and for your patience.
Please test current supported releases of Fedora Core and reopen the bug in case of any failure. I believe the bug you are describing was fixed long time ago.