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.