Re: (ITS#6478) slapd crashes with segfault

[masarati@aero.polimi.it]

> Hello, here is a backtrace
> of the crash, however not yet from
> a version with full debug symbols enabled.
> We are still working on that.

You rbacktrace, although incomplete, looks weird:

> #0  0x00000037a4e30045 in raise () from /lib64/libc.so.6
> #1  0x00000037a4e31ae0 in abort () from /lib64/libc.so.6
> #2  0x00000037a4e681bb in __libc_message () from /lib64/libc.so.6
> #3  0x00000037a4e6da07 in malloc_consolidate () from /lib64/libc.so.6
> #4  0x00000037a4e6f1fb in _int_free () from /lib64/libc.so.6
> #5  0x00000037a4e72a6c in free () from /lib64/libc.so.6
> #6  0x00000037a4ecabda in __vsyslog_chk () from /lib64/libc.so.6
> #7  0x00000037a4ecaf33 in __syslog_chk () from /lib64/libc.so.6
> #8  0x0000000000437869 in slapd_remove ()
> #9  0x00000037a5a062e7 in start_thread () from /lib64/libpthread.so.0
> #10 0x00000037a4ece3bd in clone () from /lib64/libc.so.6

libc is raising an assertion during a free related to printing something
on syslog.  However, in slapd_remove() I don't see anything that could be
harmful for syslog, as the only information that may be printed is printed
at a very verbose loglevel, and basically consists of integers, so it
seems impossible that things like NULL or invalid pointers slip through.

p.