Bug 143017 - LDAP read causes slapd crash in OpenLDAP
LDAP read causes slapd crash in OpenLDAP
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: openldap (Show other bugs)
4
i686 Linux
medium Severity high
: ---
: ---
Assigned To: Jan Safranek
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-12-15 14:43 EST by Ed Holden
Modified: 2007-11-30 17:10 EST (History)
1 user (show)

See Also:
Fixed In Version: openldap-servers-2.3.30-2.fc6
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-05-24 10:50:45 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Ed Holden 2004-12-15 14:43:46 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).
Comment 1 Ed Holden 2005-03-31 14:52:54 EST
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
Comment 2 Christian Iseli 2007-01-22 06:37:40 EST
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.
Comment 3 Matthew Miller 2007-04-06 11:05:19 EDT
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.
Comment 4 Jan Safranek 2007-05-24 10:50:45 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.