[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Slapd deadlock on Solaris 7?
Hi,
I am planning to migrate a small network currently with NIS+ as
directory service to LDAP+SSL(and SASL/Kerberos probably), so I am
performing a test in a small Solaris 7 box (microSPARC I 50 MHz, 24 Mb
RAM). Previously, I have done some tests on a couple of Debian Linux
PC's, without problems, but the server will reside in a Solaris(9)
box so I wanted to check OpenLDAP in a similar environment.
I compiled OpenLDAP 2.0.27(on a Solaris 7 UltraSPARC-IIi), with this
options:
./configure \
--disable-debug --enable-syslog --enable-proctitle \
--enable-cache --enable-referrals \
--enable-slapd --with-threads \
--enable-crypt --enable-passwd --enable-kpasswd \
--enable-rlookups --enable-slurpd \
--enable-wrappers --enable-dynamic --disable-dnssrv \
--enable-ldbm --enable-spasswd \
--enable-slurpd --enable-shared --with-tls \
--prefix=/home/samuel/extra --with-cyrus-sasl
Then I installed and configured OpenLDAP in the old machine and
configured it to resolv usernames and groups(using nss_ldap and only
itsef or a Linux PC as a client). At first, all seemed OK, but minutes
later, it was unable to resolve any non-local uid number-username
correspondence, and the slapd process was consumming all CPU time with a
simple (blocked) $ ls -l
Killing the process and inspecting the coredump, shows this backtrace:
(gdb) backtrace
#0 0xef25669c in _lwp_sema_wait ()
#1 0xef12b04c in _park ()
#2 0xef12ad40 in _swtch ()
#3 0xef129a00 in cond_wait ()
#4 0xef129924 in pthread_cond_wait ()
#5 0xef74ced8 in ldap_pvt_thread_cond_wait ()
#6 0xef74c980 in ldap_int_thread_pool_wrapper ()
So I thought it was a threads problem. I compiled again with
"--without-threads",and the same occured , but the backtrace
showed:
#0 0xef2d3378 in _so_accept ()
#1 0x1cacc in ?? ()
#2 0xef77b4d8 in ldap_pvt_thread_create (thread=0xeffff904, detach=0, start_routine=0x1c724,
arg=0x0) at thr_stub.c:48
#3 0x1cf78 in ?? ()
#4 0x1bb8c in ?? ()
So, what's happenning here? Is it a slapd bug? a gcc one? Have I done
something wrong?
Thanks in advance
Samuel