root@FreeBSD [~]$ ldd /usr/local/libexec/slapd /usr/local/libexec/slapd:libldap_r-2.4.so.2 => /usr/local/lib/libldap_r-2.4.so.2 (0x8009a7000)
liblber-2.4.so.2 => /usr/local/lib/liblber-2.4.so.2 (0x800bf5000)
libltdl.so.7 => /usr/local/lib/libltdl.so.7 (0x800e03000)
libcrypt.so.5 => /lib/libcrypt.so.5 (0x80100c000)
libwrap.so.6 => /usr/lib/libwrap.so.6 (0x80122c000)
libssl.so.7 => /usr/lib/libssl.so.7 (0x801435000)
libcrypto.so.7 => /lib/libcrypto.so.7 (0x8016a0000)
libthr.so.3 => /lib/libthr.so.3 (0x801a93000)
libc.so.7 => /lib/libc.so.7 (0x801cb8000)
root@FreeBSD [~]$ ls -lach /lib/libthr.so.3
-r--r--r-- 1 root wheel 103K 18 Jan 15:36 /lib/libthr.so.3
So as all the other Applications using "libthr.so.3" slapd should also
be able to use it?! I'm not 100% convinced yet, that this diagnosis is
going into the right direction here. I think I'll provide a second gdb
output, since it always seems to break down at a different point and action.
Am 28.04.15 um 02:49 schrieb Howard Chu:
Howard Chu wrote:Howard Chu wrote:Assuming you compiled the latest snapshot, the SEGV at back-mdb/search.c:404 makes not much sense, it's a return statement. Also, as back-mdb didn't exist 5 years ago, this cannot be the same issue you've been running into all the time. Perhaps you've hit a stack overrun. Generally slapd uses 8MB stacks on 64bit machines. It seems from your ulimit output that 8MB should be fine, so that also seems unlikely.Ah, yes, this is a known issue with FreeBSD. http://www.openldap.org/lists/openldap-bugs/200506/msg00174.htmlFurthermore, in the intervening 10 years, the FreeBSD developers have not yet fixed this issue.http://lists.freebsd.org/pipermail/freebsd-current/2014-August/051646.html