On 01/27/2016 12:33 PM, Todor Petkov wrote:
On 1/27/2016 10:20 PM, Mark Reynolds wrote:
The server is crashing in the NSS library:
Program terminated with signal 4, Illegal instruction. #0 0x00007f82f5bdad60 in ?? () from /usr/lib64/libfreeblpriv3.so
Thread 1 (Thread 0x7f82d7fff700 (LWP 25001)): #0 0x00007f82f5bdad60 in ?? () from /usr/lib64/libfreeblpriv3.so No symbol table info available. #1 0x00007f82f5bd7998 in ?? () from /usr/lib64/libfreeblpriv3.so No symbol table info available. #2 0x00007f82f5ba0b36 in ?? () from /usr/lib64/libfreeblpriv3.so No symbol table info available. #3 0x00007f82f5ba10f3 in ?? () from /usr/lib64/libfreeblpriv3.so No symbol table info available. #4 0x00007f82f60a9aef in ?? () from /usr/lib64/libsoftokn3.so No symbol table info available. #5 0x00007f82f60aa504 in ?? () from /usr/lib64/libsoftokn3.so No symbol table info available. #6 0x00007f8300684dbe in PK11_Decrypt () #7 0x00007f83009902bd in ssl3_AESGCM (} #8 0x00007f83009952fd in ssl3_HandleRecord () #9 0x00007f830099669f in ssl3_GatherCompleteHandshake () #10 0x00007f8300999022 in ssl_GatherRecord1stHandshake () #11 0x00007f83009a0185 in ssl_Do1stHandshake () #12 0x00007f83009a13b7 in ssl_SecureRecv () #13 0x00007f83009a5402 in ssl_Recv () ... ...
This might be a known issue with NSS. What version of 389 and NSS are you using?
rpm -qa | grep 389-ds-base rpm -qa | grep "^nss"
389-ds-base-1.2.11.15-68.el6_7.x86_64 389-ds-base-debuginfo-1.2.11.15-68.el6_7.x86_64 389-ds-base-libs-1.2.11.15-68.el6_7.x86_64
nss-3.19.1-8.el6_7.x86_64 nss-softokn-freebl-3.14.3-23.el6_7.x86_64 nss-util-3.19.1-2.el6_7.x86_64 nss-softokn-3.14.3-23.el6_7.x86_64 nss-sysinit-3.19.1-8.el6_7.x86_64 nss-debuginfo-3.19.1-8.el6_7.x86_64 nss-tools-3.19.1-8.el6_7.x86_64
-- 389 users mailing list 389-users@%(host_name)s http://lists.fedoraproject.org/admin/lists/389-users@lists.fedoraproject.org
You might have hit a nss-softokn - processor mismatch issue. Could you please try this workaround?
We would like to know setting the following environment variable(s) changes the behavior. 1) Open /etc/sysconfig/dirsrv and add the following line: export NSS_DISABLE_HW_GCM=1 Restart the Directory Server. Does the LDAP/TLS request crash the server? 2) If the server still crashes, add another variable to /etc/sysconfig/dirsrv: export NSS_DISABLE_HW_AES=1 Restart the Directory Server. Does the LDAP/TLS request crash the server?