Original Post: https://forums.freebsd.org/threads/thread-stack-size-segmentation-fault.51419/
It seems like FreeBSD has some serious issue with the thread stack size.
Since quite some time I have problems with two applications
Both seem to suffer under an issue of the same origin. Both receive a SIGSEGV at some sporadic point of execution. No clear pattern of an exact reproduction can be extracted of all debugging done this far.
Munin runs with more than around 100 plug-ins and about 150 graphs (times 4x, for day, week, month, year).
OpenLDAP actually does not have that much of an workload. Regular PAM via nslcd(8). Some crashes happened every couple of hours or even only days. I wrote a supervisor script, in order to have a workaround for production usage. But since the mail server (Dovecot & Postfix) are connected to it - LDAP crashes with segmentation fault after a few seconds of work. Notice, that there is only one single test user connected. So now I am at the point where my logs are flooded with connection errors more then with successful connections. The workaround does not qualify to be usable any longer.
This was enough for me to finally go into deeper debugging, than done before related to this issue. It turns out this might pretty much possible a FreeBSD OS bug. I was not happy to find this out, cause I would love to continue using FreeBSD for my server environment.
Here are the relevant links about the OpenLDAP related SIGSEGV issue and the debug output:
OpenLDAP Mailing List:
Link 11, 12 and 13 point out that it is likely to be a FreeBSD problem described on:
Also ldd(1) shows a correct link to libthr.so.3
root@FreeBSD [~]$ ldd /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
I just re-compiled the entire system with the same configuration, and it is still the same results. Why is this happening? Please let me know if I can provide some more information to fix this as soon as possible.
Try setting the environment variable LIBPTHREAD_BIGSTACK_MAIN before starting slapd. This will use the entire RLIMIT_STACK for the initial thread. This is now the default behavior in 10-stable and will be the default in 10.2 (so 10.2 should work out of the box).
Can you confirm that this is fixed either in 10.2+ or with LIBPTHREAD_BIGSTACK_MAIN?
This PR hasn't seen any activity in a while and it seems that the problem should be fixed on recent versions of FreeBSD. Please reopen if it is still a problem.