segmentation fault when attempting to delete olcOverlay={0}syncprov entry in cn=config (Runtime) Configuration

[jon brandt <jonb66@gmail.com>]

I looked but couldn't find a match to this issue, so was wondering if anyone else has seen something like it or can tell what might be wrong in my configuration.  Thanks in advance!

I'm using OpenLDAP version 2.4.21-47.1 (here is the relevant output from "rpm -qa | grep ldap" on my server):

openldap2-client-2.4.21-51.1
openldap2-2.4.21-47.1
openldap2-back-meta-2.4.21-51.1

I'm trying to get Multi-master replication working between 2 servers.  In my testing, I have discovered that when I try to reset the server (remove the configuration and start again) it crashes when trying to remove the olcOverlay={0}syncprov,olcDatabase={0}config,cn=config entry in the cn=config tree.  I attached a screen shot of the output from tracing with slapd -d -1 when the fault happened in the attached file called segFaultOutput.bmp.

If I restart the server, I can run the test again (which configures the olcOverlay={0}syncprov entry and then removes it) and it will work the first time, but if I run it a second time it will crash. 

Here is the configuration from the ldif files in /etc/openldap/slapd.d

cn=config.ldif:

dn: cn=config
objectClass: olcGlobal
cn: config
structuralObjectClass: olcGlobal
entryUUID: 8d35d270-286b-102f-998d-8313efe688a2
creatorsName: cn=config
createTimestamp: 20100720165657Z
entryCSN: 20100720165733.055688Z#000000#00c#000000
modifiersName: cn=manager,cn=config
modifyTimestamp: 20100720165733Z
contextCSN: 20100720165732.317584Z#000000#000#000000
contextCSN: 20100720165733.125549Z#000000#00c#000000


cn=schema.ldif:

dn: cn=schema
objectClass: olcSchemaConfig
cn: schema
structuralObjectClass: olcSchemaConfig
entryUUID: 8d35e49a-286b-102f-998e-8313efe688a2
creatorsName: cn=config
createTimestamp: 20100720165657Z
entryCSN: 20100720165657.613177Z#000000#000#000000
modifiersName: cn=config
modifyTimestamp: 20100720165657Z


olcDatabase={0}config.ldif:

dn: olcDatabase={0}config
objectClass: olcDatabaseConfig
olcDatabase: {0}config
olcAccess: {0}to * by * none
olcRootDN: cn=manager,cn=config
olcRootPW:: Y29uZmln
structuralObjectClass: olcDatabaseConfig
entryUUID: 8d37bc20-286b-102f-9993-8313efe688a2
creatorsName: cn=config
createTimestamp: 20100720165657Z
entryCSN: 20100720165657.625245Z#000000#000#000000
modifiersName: cn=config
modifyTimestamp: 20100720165657Z


olcDatabase={1}bdb.ldif:

dn: olcDatabase={1}bdb
objectClass: olcDatabaseConfig
objectClass: olcBdbConfig
olcDatabase: {1}bdb
olcDbDirectory: /var/lib/ldap
olcSuffix: dc=phoenix,dc=com
olcRootDN: cn=manager,dc=phoenix,dc=com
olcRootPW:: c2VjcmV0
structuralObjectClass: olcBdbConfig
entryUUID: 8d37ea88-286b-102f-9995-8313efe688a2
creatorsName: cn=manager,cn=config
createTimestamp: 20100720165657Z
entryCSN: 20100720165733.125549Z#000000#00c#000000
modifiersName: cn=manager,cn=config
modifyTimestamp: 20100720165733Z


olcDatabase={-1}frontend.ldif:

dn: olcDatabase={-1}frontend
objectClass: olcDatabaseConfig
objectClass: olcFrontendConfig
olcDatabase: {-1}frontend
olcAddContentAcl: FALSE
olcLastMod: TRUE
olcMaxDerefDepth: 0
olcReadOnly: FALSE
olcSchemaDN: cn=Subschema
olcSyncUseSubentry: FALSE
olcMonitoring: FALSE
structuralObjectClass: olcDatabaseConfig
entryUUID: 8d37c1a2-286b-102f-9994-8313efe688a2
creatorsName: cn=config
createTimestamp: 20100720165657Z
entryCSN: 20100720165657.625397Z#000000#000#000000
modifiersName: cn=config
modifyTimestamp: 20100720165657Z


the cn=schema directory has the following (I'm not going to paste the contents of these files):

cn={0}core.ldif
cn={1}cosine.ldif
cn={2}inetorgperson.ldif
cn={3}nis.ldif

Attachment: segFaultOutput.bmp
Description: Windows bitmap