Hide Forgot
Description of problem: After performing major addition/deletion of directory entries, subsequent minor additions/deletions result in an entry containing an attribute with the value being the bind DN, whereas that attribute was never set to that value in any of the operations. Version-Release number of selected component (if applicable): Server: openldap-2.4.23-31.el6.x86_64 openldap-clients-2.4.23-31.el6.x86_64 openldap-servers-2.4.23-31.el6.x86_64 Client: openldap-2.4.23-32.el6_4.1.x86_64 openldap-clients-2.4.23-32.el6_4.1.x86_64 How reproducible: Always Steps to Reproduce: 1. Extract the attached "attribute_gets_bind_dn_value.tar.gz". 2. Go to the resulting "attribute_gets_bind_dn_value" directory. 3. Use "config.ldif" and "base.ldif" as the reference for the directory server setup. 4. Modify the "stress.sh" file to match local setup. 5. Make sure lua is installed. 6. Add the extracted directory to PATH, for example with "export PATH=`pwd`:$PATH" command. 7. Run "stress_make" - it will take 10-15 minutes. 8. Run "stress_check" 9. If need to repeat "stress_check", run "stress_cleanup" then go to step 8. Actual results: Output of "stress_check": # Iteration 1 # Iteration 2 # Corrupted attribute encountered in an entry: dn: cn=group10000,ou=Groups,dc=example,dc=com objectClass: extensibleObject objectClass: groupOfNames gidNumber: 10000 cn: group10000 member: cn=Manager,dc=example,dc=com Expected results: Output of "stress_check": # Iteration 1 # Iteration 2 # Iteration 3 # Iteration 4 # Iteration 5 # Iteration 6 # Iteration 7 # Iteration 8 # Iteration 9 # Iteration 10 Additional info: See the attached ldap.pcap for a traffic capture of a ldapsearch followed by a "stress_check" execution. The problem didn't reproduce when slapd was executed under Valgrind. The problem didn't reproduce with openldap-servers-2.4.35-1.el6.x86_64.
Created attachment 814477 [details] attribute_gets_bind_dn_value.tar.gz
Created attachment 814478 [details] ldap.pcap
Clarification to the Valgrind note: after "stress_make" was run, a subsequent "stress_check" run failed, slapd was stopped and started under Valgrind, another "stress_check" run didn't fail. Moreover, after the slapd started under Valgrind was stopped and started again with the regular "service" command, "stress_check" runs stopped failing.
I managed to reproduce this a few times, but can't anymore...
Thank you, Jan. Unfortunately I couldn't reproduce it again in a short span of time, and then it got buried by other matters. Let's hope it got fixed.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHBA-2014-1426.html