Hide Forgot
Description of problem: I am using Scientific Linux 6.1 (a free Red Hat Enterprise Linux derivative). I used openldap-2.4.19-15.el6_0.2.x86_64 since July 2011 without any problem. Since the upgrade to openldap-2.4.23-15.el6.x86_64 applied on 18 January 2012, we are experimenting unexpected slapd server crashes. Nothing is written in the log, no core is created. Tried to solve installing openldap-2.4.23-15.el6_1.3.x86_64 (from fastbugs repository), but it crashed too. Version-Release number of selected component (if applicable): 2.4.23-15.el6.x86_64 2.4.23-15.el6_1.3.x86_64 How reproducible: Not really reproducible, but on a cloned server containing the same users database, I run 20 processes running the following script until slapd crashed (it took about 2 hours). #!/bin/bash for ((;1==1;)) do ldapsearch -x -v -h ldap1core.icgeb.org "uid=palmi"> /dev/null 2>&1 ldapsearch -x -v -h ldap1core.icgeb.org "uid=palmi" -ZZ > /dev/null 2>&1 ldapsearch -x -v -h ldap1core.icgeb.org "mail=Dario.Palmisano" -ZZ > /dev/null 2>&1 done Steps to Reproduce: 1. 2. 3. Actual results: After a couple of hours slapd exited (crashed) without any message in /var/log/ldap.log (slapd.conf had loglevel 256) or /var/log/messages. Expected results: slapd should continue working Additional info:
I forgot to mention that trying to restart slapd, produces in /var/log/messages: Feb 2 15:41:42 helixcore kernel: slapd[15304] general protection ip:7feb610401e2 sp:7feb3affc7b0 error:0 in libssl3.so[7feb61024000+32000]
Hello Dario, please, update. This bug was fixed in openldap-2.4.23-19.el6 (#709407, #701678). I'm closing this report. If you believe, that this is not the same bug: reopen this bug, provide both your client and server configuration (with obfuscated data) and backtrace (install and configure ABRT to catch the core dump, extract the backtrace using gdb). Jan