[Date Prev][Date Next]
Re: RE24 testing call #1 (OL 2.4.24)
>>> 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
> up in test036 for me, I never get as far as test039. The gdb trace looks
> the same as what you posted.
> Looks like for some reason threads that are blocked waiting for their
> 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
> the writable status.
> I haven't used this Solaris machine much, but in fact (looking at the
> 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
> 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
ldap_pvt_thread_mutex_unlock error: !THREAD_MUTEX_OWNER( mutex )
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.
Linux fl1 126.96.36.199-0.5-desktop #1 SMP PREEMPT 2010-10-25 08:40:12 +0200
x86_64 x86_64 x86_64 GNU/Linux