+++ This bug was initially created as a clone of Bug #701227 +++ Steps to reproduce: 1) find or create an attribute which has an ORDERING matching rule (and not via inheritance - that's another bug) ldapmodify -x -h localhost -p 1389 -D "cn=directory manager" -w ggg -v << EOF dn: cn=schema changetype: modify add: attributetypes attributeTypes: (1.3.6.1.4.1.34217.1.1.1.2.6 NAME 'nzCoSkyReceiveMarketingNewsLetter' DESC 'Whether the user opts to receive SKY TV news letters' EQUALITY booleanMatch ORDERING booleanMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 SINGLE-VALUE) add attributeTypes: (1.3.6.1.4.1.34217.1.1.1.2.6 NAME 'nzCoSkyReceiveMarketingNewsLetter' DESC 'Whether the user opts to receive SKY TV news letters' EQUALITY booleanMatch ORDERING booleanMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 SINGLE-VALUE) modifying entry "cn=schema" modify complete 2) add or change the index for the attribute to have an nsMatchingRule with one of the l10n matching rules defined by the collation plugin e.g. 2.16.840.1.113730.3.3.2.11.1 for en or en-US [root@rheltest slapd-rheltest]# ldapmodify -a -D "cn=directory manager" -w ggg -p 1389 -h localhost << EOF > dn: cn=nzCoSkyReceiveMarketingNewsletter,cn=index,cn=userRoot,cn=ldbm > database,cn=plugins,cn=config > changetype: add > objectClass: top > objectClass: nsIndex > cn:nzCoSkyReceiveMarketingNewsletter > nsSystemIndex:false > nsIndexType:eq > nsMatchingRule: 2.16.840.1.113730.3.3.2.6.1 > nsMatchingRule: 2.16.840.1.113730.3.3.2.11.1 > EOF ldapmodify: invalid format (line 2) entry: "cn=nzCoSkyReceiveMarketingNewsletter,cn=index,cn=userRoot,cn=ldbm" Segmentation fault (core dumped) Note: The dn: .. line must be all one line. It looks like the line ends at cn=ldbm and a new line begins at database,. But still it should not be a Segmentation fault (core dumped). --- Additional comment from rmeggins on 2011-05-02 16:43:43 CEST --- looks like the problem is if the dn: line continues but does not begin with a space char (as in proper LDIF continuation line wrapping) ldapmodify will crash. --- Additional comment from jvcelak on 2011-06-22 11:56:55 CEST --- Created attachment 505957 [details] proposed patch Attaching proposed patch. I have also created an upstream report and submitted the patch: http://www.openldap.org/its/index.cgi?findid=6978 --- Additional comment from jvcelak on 2011-06-24 09:05:50 CEST --- Created attachment 509682 [details] upstream patch Upstream included a different fix,
(This issue is resolved in Rawhide with openldap-2.4.25-1.fc16.)
Fixed in openldap-2.4.24-3.fc15
openldap-2.4.24-3.fc15 has been submitted as an update for Fedora 15. https://admin.fedoraproject.org/updates/openldap-2.4.24-3.fc15
Package openldap-2.4.24-3.fc15: * should fix your issue, * was pushed to the Fedora 15 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing openldap-2.4.24-3.fc15' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/openldap-2.4.24-3.fc15 then log in and leave karma (feedback).
openldap-2.4.24-3.fc15 has been pushed to the Fedora 15 stable repository. If problems still persist, please make note of it in this bug report.