Both, as well as when running the head tests suite with the 2.4.23 release. Looks as if the swamp additions have tripped into an existing problem, not anything new. Leave it out of RE24 until if have been resolved?
Btw, any other Solaris test runs out there? IĀ“t like to know if it is a real Solaris problem or just me..
I'm seeing a similar failure on 32 bit Sparc Solaris 10. But it actually locks up in test036 for me, I never get as far as test039. The gdb trace looks much the same as what you posted.
Looks like for some reason threads that are blocked waiting for their sockets to become writable are never getting waken up. A regular SIGINT shuts down slapd cleanly so it doesn't appear to be a problem with the condvars being used to manage the threads. That kinda points to select() simply not returning the writable status.
I haven't used this Solaris machine much, but in fact (looking at the remnants of other files in my source tree on this box) this appears to have been a problem since at least last August. (I.e., it looks like I was investigating this same problem back then but dropped it and never got back to it.)
Not sure whether it is related, but I'm currently running test036 with -DLDAP_THREAD_DEBUG (for unrelated purposes) and I see some mutex-related failures, of the type
conn=1031 op=1 SRCH base="cn=Monitor" scope=2 deref=0 filter="(objectClass=*)" ../../../ldap-2.4-src/libraries/libldap_r/thr_debug.c:1029: ldap_pvt_thread_mutex_unlock error: !THREAD_MUTEX_OWNER( mutex ) ../../../ldap-2.4-src/libraries/libldap_r/thr_debug.c:1033: ldap_pvt_thread_mutex_unlock error: rc is 1
I see a lot of them; they always appear within operations affecting back-monitor, this seems to be consistent with Rein's backtrace.
uname -a Linux fl1 2.6.34.7-0.5-desktop #1 SMP PREEMPT 2010-10-25 08:40:12 +0200 x86_64 x86_64 x86_64 GNU/Linux
p.