Re: (ITS#4429) (back-ldap?) slapd deadlock

[richton@nbcs.rutgers.edu]

> I'll try adding a conn-ttl to tests and see if it matters.

tests wasn't good (I need some HEAD patches there) but I readded conn-ttl
in production (with intent of breaking) and caught a failure about two
hours later. I can provide the full log or turn up levels if it will help.

last bit of log:
conn=174 fd=12 ACCEPT from IP=128.6.17.195:63242 (IP=0.0.0.0:389)
conn=174 op=0 STARTTLS
conn=174 op=0 RESULT oid= err=0 text=
conn=174 fd=12 TLS established tls_ssf=256 ssf=256
conn=174 op=1 BIND dn="" method=128
send_ldap_result: conn=174 op=1 p=3
conn=174 op=1 RESULT tag=97 err=0 text=
conn=174 op=2 SRCH base="uid=chrisjs,ou=People,dc=rci,dc=rutgers,dc=edu"
scope=2 deref=0 filter="(objectClass=*)"
==> limits_get: conn=174 op=2 dn="[anonymous]"
send_ldap_result: conn=174 op=2 p=3
send_ldap_result: err=53 matched="" text=""
conn=174 op=2 SEARCH RESULT tag=101 err=53 nentries=0 text=
ber_flush: 14 bytes to sd 12
conn=174 op=2 SEARCH RESULT tag=101 err=53 nentries=0 text=

At this point slapd is useless.

You'll also notice no messages from
ldap_back_getconn/ldap_back_retry/ldap_create like you might expect after
the limits_get Debug.


current thread: t@1
  [1] __lwp_wait(0x2, 0xffbffb54, 0xff3162a0, 0xfec324fc, 0x2, 0xffbffb1c), at 0xfed1fc38
  [2] lwp_wait(0x2, 0xffbffb54, 0x46220, 0xff303d34, 0x5, 0xffbffb4c), at 0xfec3d6b0
  [3] _thrp_join(0x2, 0x0, 0x0, 0x1, 0x81010100, 0xff00), at 0xfec390e8
=>[4] ldap_pvt_thread_join(thread = 2U, thread_return = (nil)), line 193 in "thr_posix.c"
  [5] slapd_daemon(), line 2239 in "daemon.c"
  [6] main(argc = 6, argv = 0xffbffd6c), line 854 in "main.c"
current thread: t@2
  [1] _poll(0xfe3fd4d8, 0x9, 0x16378, 0x0, 0x5b, 0xfe3fd6e1), at 0xfed1df0c
  [2] select_large_fdset(0x1f, 0x20, 0xfe3fd6e0, 0x0, 0xfe3fd6e0, 0xfe3fd6e0), at 0xfecd2be0
=>[3] slapd_daemon_task(ptr = (nil)), line 1840 in "daemon.c"
current thread: t@3
  [1] __lwp_park(0x0, 0x0, 0x0, 0x1, 0xfec58000, 0x0), at 0xfec45994
  [2] cond_wait_queue(0x2c0620, 0xfec58b48, 0x0, 0x0, 0xfec20400, 0xfec58000), at 0xfec42b9c
  [3] _cond_wait_cancel(0x2c0620, 0x2c0608, 0x22dda8, 0xae, 0xc, 0x0), at 0xfec43358
  [4] _ti_pthread_cond_wait(0x2c0620, 0x2c0608, 0xfdbffd3c, 0x0, 0x0, 0x0), at 0xfec43394
=>[5] ldap_pvt_thread_cond_wait(cond = 0x2c0620, mutex = 0x2c0608), line 298 in "thr_posix.c"
  [6] ldap_int_thread_pool_wrapper(xpool = 0x2c0600), line 468 in "tpool.c"
current thread: t@4
  [1] __lwp_park(0x0, 0x0, 0x0, 0x1, 0xfec58000, 0x27d2d0), at 0xfec45994
  [2] cond_wait_queue(0x2c0620, 0xfec58b48, 0x0, 0x0, 0xfec20600, 0xfec58000), at 0xfec42b9c
  [3] _cond_wait_cancel(0x2c0620, 0x2c0608, 0xffffffff, 0xfffffff8, 0x0, 0x623e49), at 0xfec43358
  [4] _ti_pthread_cond_wait(0x2c0620, 0x2c0608, 0xfd3ffd3c, 0x0, 0x0, 0x0), at 0xfec43394
=>[5] ldap_pvt_thread_cond_wait(cond = 0x2c0620, mutex = 0x2c0608), line 298 in "thr_posix.c"
  [6] ldap_int_thread_pool_wrapper(xpool = 0x2c0600), line 468 in "tpool.c"