Also, I just checked. It looks like slapd is successfully linked to "libthr.so.3"
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.html
Furthermore, 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