we have narrowed the problem to this: every time we add a value to a multivalued attribute for a particular dn, slapd dies. And the attribute value does not get added.

Below is the output from a wrapper we use for ldapmodify.

Could this be db corruption? The particular attribute is not indexed.

[root@aaaprod-master log]# do_ldapmod -cred=file:AUA -port=636 -v /var/tmp/dba.ldif
ldap_initialize( ldaps://localhost:636/??base )
add guemailboxalternate:
        2024252367@mms.att.net
modifying entry "uid=ncs-dba-alerts,ou=Aliases,dc=georgetown,dc=edu"
ldap_result: Can't contact LDAP server (-1)

On Fri, May 25, 2012 at 12:25 PM, Dan White <dwhite@olp.net> wrote:
On 05/25/12 11:20 -0400, David Massie wrote:
Here are the versions:

openldap 2.4.31
db4.x86_64                         4.7.25-16.el6
openssl.x86_64                     1.0.0-20.el6
cyrus-sasl-lib.x86_64              2.1.23-13.el6

Will setting the logging to DEBUG provide anything?

I think that would depend on how the section of code which generates the
abort is coded. If it produces debug output just prior to calling abort,
then you should see that.


Also, I have a question  about debugging a corefile. Our production version
fo slapd does not have debug symbols compiled in. If, on a non-production
machine, we were to compile another instance, when the same libraries,
etc., but, with debugging turned on could we run gdb against the corefile
we dropped in production against this executable?

I don't know the answer to that.

On Wed, May 23, 2012 at 6:22 PM, Dan White <dwhite@olp.net> wrote:
Which versions of slapd, libssl, berkeleydb, and libsasl are you running?

SIGABRT implies that the process ended due to an unexpected condition
occurring within either a library or slapd itself. Were any core dumps
generated? If not, enable core dumps and get a backtrace from within gdb.
It should point you to the section of code which is triggering the abort.

--
Dan White