[Date Prev][Date Next] [Chronological] [Thread] [Top]

RE: SLAPD Crashing due to search (ITS#1840)



Kurt,
	Could this be related to ITS#1570? I'm running RedHat's
precompiled 2.0.21/23, and it occurs on both versions. Also, I don't get
a core dump, which from my understanding is how you can get a stack
trace...

	It's 100% reproducible - I'm happy to share my entire directory
if needs be (it 4MBytes - 1.3MB gzipped), schema file, and the script
I've hacked together to force the crash.

Regards
Garry


> -----Original Message-----
> From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org] 
> Sent: Sunday, 2 June 2002 4:33 AM
> To: gthomas@netstarnetworks.com
> Cc: openldap-its@OpenLDAP.org
> Subject: Re: SLAPD Crashing due to search (ITS#1840)
> 
> 
> At 04:23 AM 2002-05-28, gthomas@netstarnetworks.com wrote:
> >Full_Name: Garry Thomas
> >Version: 2.0.21
> >OS: Linux Redhat 7.2
> >URL: ftp://ftp.openldap.org/incoming/
> >Submission from: (NULL) (210.49.137.29)
> 
> Upgrade to 2.0.23.
> 
> 
> 
> >Hi,
> > I have 'semi' reproducible slapd crash since upgrading from 
> 2.0.11 to 
> >2.0.21 (or 2.0.23). When I issue a simple search as follows...
> >
> >ldapsearch -x -h 127.0.0.1 -b dc=netstarnetworks,dc=com 
> '(uid=manka01)'
> >
> >all is OK, and I get the expected result.
> >
> >However, when a search as follows is done (which is what 
> happens when 
> >the uid receives an email cause I'm using ldap authentication)
> >
> >ldapsearch -x -h 127.0.0.1 -b dc=netstarnetworks,dc=com 
> >'(&(objectClass=posixAccount)(uid=manka01))'
> >
> >it just crashes slapd. This only seems to occur on 'random' 
> dn's. (I've 
> >captured this one, and am leaving it so I can fault find). I 
> got this 
> >search by enabling debug and sending the uid an email. It occurs on 
> >more than one slapd slave server, some running 2.0.21 some 2.0.23. I 
> >didn't have this problem when I was running 2.0.11, but this version 
> >had indexing issues, so I have to upgrade.
> >
> >I've got a time bomb going on here.... when ldap fails, 
> emails bounce. 
> >My temp workaround.... the master LDAP server is still 
> running 1.2.13, 
> >and it doesn't crash. Why am I running 1.2.13? it a long story... I 
> >still have old 1.2.x slaves, and these don't handle LDAP Protocol 
> >Version 3, which is what the 2.0.x slurpd's use... I'm kinda lucky I 
> >haven't upgraded the master yet...;)
> >
> >The result from the first search that doesn't crash the server is 
> >below. This is a test account so I'm not concerned about the 
> >sensitivity of the information below.
> >
> >Help...
> >
> >Thanks Garry
> >
> >ldapsearch -x -h 127.0.0.1 -b dc=netstarnetworks,dc=com 
> '(uid=manka01)'         
> >                   
> >version: 2
> >
> >#
> ># filter: (uid=manka01)
> ># requesting: ALL
> >#
> >
> ># manka01, netstarnetworks, com
> >dn: uid=manka01,dc=netstarnetworks,dc=com
> >givenName: Kavi
> >sn: Man
> >mail: oracle@netstarnetworks.com
> >uid: manka01
> >cn: Kavi Man
> >objectClass: top
> >objectClass: posixAccount
> >objectClass: person
> >objectClass: NetStarPerson
> >objectClass: inetOrgPerson
> >loginShell: /bin/bash
> >homeDirectory: /home/manka01
> >uidNumber: 2194
> >gidNumber: 1000
> >
> ># search result
> >search: 2
> >result: 0 Success
> >
> ># numResponses: 2
> ># numEntries: 1
>