>>> 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.
