Please test RE24 heavily.

-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAk0kLLYACgkQRAx5nvEhZLIsxACeMaAV7f/j627u+KILaWTVX+Vr iNMAnjW1uEOpa6RDhXwDMWIlgkZXxRct =1rpB -----END PGP SIGNATURE-----

Please test RE24 heavily. Thanks! --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

This was just a checkpoint to make sure what was done so far doesn't break anything.

> Some issues it'd be nice to have in, if they're simple for those who > know the code in question: > > ITS#6760 rwm broken entry handling > Fixed, I think, but needs review This will be in the next set.

> ITS#6532 Support for common orderingMatching rules in extensible match > filters TODO: Handle CSN and UUID ordering match too? > (Almost certainly OK, but I wanted someone who knows to say so. It's > a two-line update, setting the SLAP_MR_EXT flag for these rules.) > > Also, possibly the rest of "ITS#6739 broken do_syncrep2()" is simple. > Almost fixed. If you get these committed, I can add them.

Please test RE24 heavily.

On 04.01.11 23.34, Quanah Gibson-Mount wrote: > Please test RE24 heavily. test039 deadlocks for me on 64bit solaris10, both x86 and sparc :-( It hangs in the monitor, triggered by the new swamp -SS option added to slapd-tester. It works if run with -S or -SSS. It is the third server that hangs, and it does so quite consistently with the same stack trace every time. A gdb trace is at at: ftp://ftp.openldap.org/incoming/rein-test039-gdb-trace.txt No problem on 64bit x86 redhat4.

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

On 01/ 7/11 08:01 AM, Rein Tollevik wrote: > On 06.01.11 22.48, Quanah Gibson-Mount wrote: >> --On Thursday, January 06, 2011 7:40 PM +0100 Rein Tollevik >> <rein(a)OpenLDAP.org&gt; wrote: >> >>> On 04.01.11 23.34, Quanah Gibson-Mount wrote: >>>> Please test RE24 heavily. >>> >>> test039 deadlocks for me on 64bit solaris10, both x86 and sparc :-( It >>> hangs in the monitor, triggered by the new swamp -SS option added to >>> slapd-tester. It works if run with -S or -SSS. It is the third server >>> that hangs, and it does so quite consistently with the same stack trace >>> every time. A gdb trace is at at: >>> >>> ftp://ftp.openldap.org/incoming/rein-test039-gdb-trace.txt >> >> Does this happen on both HEAD and RE24, or RE24 only? > > 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..

> Rein

I'm currently testing Solaris11 (Nevada) and not seeing any issues in either 32 or 64 bit builds using both RE24 and HEAD. I have not had any failures on x86 yet. Testing is still underway for sparc and other internal system testing on both platforms.

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 )

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

Howard Chu wrote: > masarati(a)aero.polimi.it wrote: >> >>>>> 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. Since there are reports of success on Solaris 9 and Solaris 11 I'm content to pass this off as a bug in Solaris 10. In the meantime, all tests are now passing for me in HEAD on Solaris 10 with ITS#6783 and #6787 patches.