RE: 2.0.1[15] hangs on Solaris 8 in test10-passwd.

["Howard Chu" <hyc@highlandsun.com>]

The last time I checked, my Solaris systems didn't come with a /dev/random.
What do you have installed on your system to provide /dev/random
functionality?

  -- Howard Chu
  Chief Architect, Symas Corp.       Director, Highland Sun
  http://www.symas.com               http://highlandsun.com/hyc

> -----Original Message-----
> From: owner-openldap-software@OpenLDAP.org
> [mailto:owner-openldap-software@OpenLDAP.org]On Behalf Of Nicholas
> Dronen

> Hi,
>
> I'm running 2.0.15 with gdbm.  I've seen what I believe is
> the same problem running 2.0.11 as well.  Slapd hangs in
> the following test:
>
> >>>>> Starting test010-passwd ...
> running defines.sh . ldbm
> Cleaning up in ./test-db...
> Starting slapd on TCP/IP port 9009...
> Using ldapsearch to check that slapd is running...
> Waiting 5 seconds for slapd to start...
> Using ldapadd to populate the database...
> Using ldapsearch to verify population ...
> Using ldappasswd (PASS 1)  ...
>
> Here's the truss output.
>
> poll(0xFEE0B640, 3, -1)         (sleeping...)
> signotifywait()                 (sleeping...)
> door_return(0x00000000, 0, 0x00000000, 0) (sleeping...)
> open("/dev/random", O_RDONLY)   (sleeping...)
> lwp_cond_wait(0xFF0E55C8, 0xFF0E55D8, 0xFF083C48) (sleeping...)
> lwp_cond_wait(0xFF0E55C8, 0xFF0E55D8, 0xFF083C48) Err#62 ETIME
> time()                                          = 1001613374
> poll(0xFEE0B640, 3, -1)         (sleeping...)
> signotifywait()                 (sleeping...)
> door_return(0x00000000, 0, 0x00000000, 0) (sleeping...)
> open("/dev/random", O_RDONLY)   (sleeping...)
> lwp_cond_wait(0xFF0E55C8, 0xFF0E55D8, 0xFF083C48) (sleeping...)
>
> And the pstack output.
>
> 10285:  ../servers/slapd/slapd -f ./data/slapd-pw.conf -h
> ldap://localhost:900
> -----------------  lwp# 1 / thread# 4  --------------------
>  ff19956c poll     (fee0b640, 3, ffffffff)
>  ff14c798 select   (9, 0, ff1bb1e4, fee0bbf4, fee0bc74, fee0b640) + 2cc
>  ff0cb470 select   (fee0b74e, ff0e4798, 0, 5, 1, fe401000) + 34
>  ff0cbad0 _thread_start (0, 0, 0, 0, 0, 0) + 40
> -----------------  lwp# 2 / thread# 2  --------------------
>  ff19ad30 signotifywait ()
>  ff0be8e0 _dynamiclwps (ff0de000, 5c, 0, 0, 0, 0) + 1c
>  ff0c1b88 thr_yield (0, 0, 0, 0, 0, 0) + 8c
> -----------------  lwp# 3  --------------------------------
>  ff1988d4 door     (0, 0, 0, 0, ff0a5d18, 4)
>  ff0ba474 _lwp_start (0, 0, 0, 0, 0, 0) + 18
> -----------------  lwp# 4 / thread# 5  --------------------
>  ff199448 open     (f010c, 0, 0)
>  ff192714 _open    (f010c, 0, 0, ff1b8018, 0, 0) + 1c
>  ff0caa98 open     (fed097a8, 4, 0, 105a72, 107d16, 7d) + 34
>  0009ea0c hash_ssha1 (dc0e0, 114478, 109200, 7efefeff, 81010100,
> ff00) + 3c
>  0009d75c lutil_passwd_hash (114478, 105a6c, ff1b8018, 0,
> ff1bbcf8, fed088f8) + 8c
>  0005b6a8 slap_passwd_hash (114478, 4, efc14, 107cc8, 0, 0) + 70
>  000951e4 ldbm_back_exop_passwd (128938, 1292e0, 114bd8, 110f28,
> 1144f8, fed09c10) + 314
>  00089958 ldbm_back_extended (fed09c08, fed09c18, 94ed0, 110f28,
> 1144f8, fed09c10) + f0
>  0005a8d4 passwd_extop (fed09c08, fed09c18, 89868, 1144f8,
> fed09c10, fed09c0c) + 2c4
>  0005a0ec do_extended (fed09c18, 5a610, 10c478, ff1b8018, 0, 79fb0) + 764
>  00024340 connection_operation (114328, 0, 0, 0, 0, 0) + 368
>  000a69fc ldap_int_thread_pool_wrapper (10c470, ff093d18, 1,
> ff0eae04, 0, 2) + 19c
>  ff0cbad0 _thread_start (10c470, 0, 0, 0, 0, 0) + 40
> -----------------  lwp# 5  --------------------------------
>  ff19b314 lwp_cond_wait (ff0e55c8, ff0e55d8, ff083c48)
>  ff192cb0 _lwp_cond_timedwait (0, 3bb36a96, ff083cb0, ff0e55c8,
> ff0e55d8, 0) + 98
>  ff0b8e24 _age     (ff0dedc0, ff0dedc4, ff0de000, 3, ff0de000, 1) + 94
>  ff0ba474 _lwp_start (ff083d78, 0, 4000, ff00fc34, 0, 0) + 18
>  ff0c1b88 thr_yield (0, 0, 0, 0, 0, 0) + 8c
> --------------------------  thread# 1  --------------------
>  ff0bd9a0 _reap_wait_cancel (ff0dee38, ff0de000, 80, ff0e59a8,
> fee0bd78, 1) + 40
>  ff0bfc00 _thrp_join (ff0dee38, 4, 0, ff0de000, 0, 4) + 344
>  000a6eec ldap_pvt_thread_join (4, 0, 1dbd8, 0, ffbef020, dc74d) + 1c
>  0002067c slapd_daemon (0, 0, ff1bbe18, 109268, 0, 0) + 10c
>  0001a81c main     (7, ffbeee3c, ffbeee5c, 104000, 0, 0) + bf4
>  00019b94 _start   (0, 0, 0, 0, 0, 0) + dc
> --------------------------  thread# 3  --------------------
>  ff0bd948 _reap_wait (ff0e2a30, 20994, 0, ff0de000, 0, 0) + 38
>  ff0bd6a0 _reaper  (ff0dee58, ff0e4798, ff0e2a30, ff0dee30, 1,
> fe400000) + 38
>  ff0cbad0 _thread_start (0, 0, 0, 0, 0, 0) + 40
>
> I don't know what's preventing slapd from continuing.  It could
> be blocking while opening /dev/random, but it could also be blocking
> in lwp_cond_wait (viz., pthread_cond_wait).  If the latter is the case,
> I believe the problem is in libraries/libldap_r/tpool.c, either:
>
>     369          if (pool->ltp_state == LDAP_INT_THREAD_POOL_RUNNING)
>     370             ldap_pvt_thread_cond_wait(&pool->ltp_cond,
> &pool->ltp_mutex);
>
> or
>
>     379       (ctx->ltc_start_routine)(ctx->ltc_arg);
>
> Has anyone seen this before?  Might it be a bug in the version
> of libpthread.so on this Solaris machine?
>
> Regards,
>
> Nicholas Dronen:
>