Please test RE24.
Thanks!
--Quanah
--
Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration
Quanah Gibson-Mount quanah@zimbra.com writes:
Please test RE24.
openSUSE 11.0 x86_64 BerkeleyDB-4.7
1. test019 fails
test failed - master and P1 slave databases differ
./scripts/test019-syncreplication-cascade failed (exit 1)
2. each test reports segmentation faults i.e.
./scripts/test018-syncreplication-persist: line 259: 9652 Speicherzugriffsfehler $SLAPD -f $CONF4 -h $URI4 -d $LVL $TIMING > $LOG4 2>&1
./scripts/test018-syncreplication-persist: line 370: 9701 Speicherzugriffsfehler $SLAPD -f $CONF1 -h $URI1 -d $LVL $TIMING >> $LOG1 2>&1
./scripts/test018-syncreplication-persist: line 370: 9776 Speicherzugriffsfehler $SLAPD -f $CONF4 -h $URI4 -d $LVL $TIMING >> $LOG4 2>&1
./scripts/test018-syncreplication-persist completed OK.
-Dieter
Dieter Kluenter wrote:
Quanah Gibson-Mount quanah@zimbra.com writes:
Please test RE24.
openSUSE 11.0 x86_64 BerkeleyDB-4.7
- test019 fails
test failed - master and P1 slave databases differ
./scripts/test019-syncreplication-cascade failed (exit 1)
I can confirm this.
- each test reports segmentation faults i.e.
Which SASL libs are you using for OpenLDAP? The ones shipped with openSUSE? These are built against package libdb-4_5-4.5.20-67.1. This might cause issues.
Ciao, Michael.
Michael Ströder wrote:
Dieter Kluenter wrote:
Quanah Gibson-Mount quanah@zimbra.com writes:
Please test RE24.
openSUSE 11.0 x86_64 BerkeleyDB-4.7
- test019 fails
test failed - master and P1 slave databases differ
./scripts/test019-syncreplication-cascade failed (exit 1)
I can confirm this.
Do you confirm the error is related to "James A Jones 2" not being deleted from servers 5 and 6:
diff -u testrun/server1.flt testrun/server5.flt diff -u testrun/server1.flt testrun/server6.flt
not empty?
p.
Ing. Pierangelo Masarati OpenLDAP Core Team
SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando@sys-net.it -----------------------------------
Pierangelo Masarati wrote:
Michael Ströder wrote:
Dieter Kluenter wrote:
Quanah Gibson-Mountquanah@zimbra.com writes:
Please test RE24.
openSUSE 11.0 x86_64 BerkeleyDB-4.7
- test019 fails
test failed - master and P1 slave databases differ
./scripts/test019-syncreplication-cascade failed (exit 1)
I can confirm this.
Do you confirm the error is related to "James A Jones 2" not being deleted from servers 5 and 6:
diff -u testrun/server1.flt testrun/server5.flt diff -u testrun/server1.flt testrun/server6.flt
not empty?
I see that on server6, but server5 is correct. Also there appears to be an erroneous rename in server6.
----- Howard Chu hyc@symas.com ha scritto:
Pierangelo Masarati wrote:
Michael Ströder wrote:
Dieter Kluenter wrote:
Quanah Gibson-Mountquanah@zimbra.com writes:
Please test RE24.
openSUSE 11.0 x86_64 BerkeleyDB-4.7
- test019 fails
test failed - master and P1 slave databases differ
> ./scripts/test019-syncreplication-cascade failed (exit 1)
I can confirm this.
Do you confirm the error is related to "James A Jones 2" not being deleted from servers 5 and 6:
diff -u testrun/server1.flt testrun/server5.flt diff -u testrun/server1.flt testrun/server6.flt
not empty?
I see that on server6, but server5 is correct. Also there appears to be an erroneous rename in server6.
Actually, I have been unable to reproduce this issue. To summarize: so far, I only got a failure of test019 with re24 & db-4.7; no failures for re24 & db-4.6, so I believe the db version could be unrelated, as the issue does not seem to be repeatable here. I'll keep trying and investigating. In fact, the failure I saw, related to a non-propagated delete, seems also to occur in other tests I'm carving for HEAD, but does not show up in test050 as I modified by adding an add and a delete for each participant in the MMR pool.
p.
Ing. Pierangelo Masarati OpenLDAP Core Team
SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando@sys-net.it -----------------------------------
Pierangelo Masarati wrote:
----- Howard Chuhyc@symas.com ha scritto:
I see that on server6, but server5 is correct. Also there appears to be an erroneous rename in server6.
Actually, I have been unable to reproduce this issue. To summarize: so far, I only got a failure of test019 with re24& db-4.7; no failures for re24& db-4.6, so I believe the db version could be unrelated, as the issue does not seem to be repeatable here. I'll keep trying and investigating. In fact, the failure I saw, related to a non-propagated delete, seems also to occur in other tests I'm carving for HEAD, but does not show up in test050 as I modified by adding an add and a delete for each participant in the MMR pool.
I've definitely identified a bug in rename handling, working on a fix. The detection of deleteOldRDN is wrong, it always results in deleteOldRDN being set even if the old RDN wasn't actually deleted. There are some other problems due to modRDN falling thru to modify as well...
Howard Chu wrote:
Pierangelo Masarati wrote:
----- Howard Chuhyc@symas.com ha scritto:
I see that on server6, but server5 is correct. Also there appears to be an erroneous rename in server6.
Actually, I have been unable to reproduce this issue. To summarize: so far, I only got a failure of test019 with re24& db-4.7; no failures for re24& db-4.6, so I believe the db version could be unrelated, as the issue does not seem to be repeatable here. I'll keep trying and investigating. In fact, the failure I saw, related to a non-propagated delete, seems also to occur in other tests I'm carving for HEAD, but does not show up in test050 as I modified by adding an add and a delete for each participant in the MMR pool.
I've definitely identified a bug in rename handling, working on a fix. The detection of deleteOldRDN is wrong, it always results in deleteOldRDN being set even if the old RDN wasn't actually deleted. There are some other problems due to modRDN falling thru to modify as well...
This is now fixed in HEAD.
Pierangelo Masarati wrote:
Do you confirm the error is related to "James A Jones 2" not being deleted from servers 5 and 6:
diff -u testrun/server1.flt testrun/server5.flt diff -u testrun/server1.flt testrun/server6.flt
not empty?
Yes, the diff output is not empty.
FYI: This is libdb-4_5-4.5.20-67.1 shipped with openSUSE 11.0 i586 (32 bit).
Ciao, Michael.
Michael Ströder michael@stroeder.com writes:
Dieter Kluenter wrote:
Quanah Gibson-Mount quanah@zimbra.com writes:
Please test RE24.
openSUSE 11.0 x86_64 BerkeleyDB-4.7
- test019 fails
test failed - master and P1 slave databases differ
./scripts/test019-syncreplication-cascade failed (exit 1)
I can confirm this.
- each test reports segmentation faults i.e.
Which SASL libs are you using for OpenLDAP? The ones shipped with openSUSE? These are built against package libdb-4_5-4.5.20-67.1. This might cause issues.
OK, I will check this.
-Dieter
Michael Ströder michael@stroeder.com writes:
Dieter Kluenter wrote:
Quanah Gibson-Mount quanah@zimbra.com writes:
Please test RE24.
openSUSE 11.0 x86_64 BerkeleyDB-4.7
- test019 fails
test failed - master and P1 slave databases differ
./scripts/test019-syncreplication-cascade failed (exit 1)
I can confirm this.
- each test reports segmentation faults i.e.
Which SASL libs are you using for OpenLDAP? The ones shipped with openSUSE? These are built against package libdb-4_5-4.5.20-67.1. This might cause issues.
I just built against libdb-db-4.5 but still segmentation faults for each and every test remain, just an exmaple:
/scripts/test017-syncreplication-refresh: line 269: 32282 Speicherzugriffsfehler $SLAPD -f $CONF1 -h $URI1 -d $LVL $TIMING > $LOG1 2>&1 ./scripts/test017-syncreplication-refresh: line 269: 32328 Speicherzugriffsfehler $SLAPD -f $CONF2 -h $URI2 -d $LVL $TIMING > $LOG2 2>&1
ldd /work/openldap/servers/slapd/.libs/lt-slapd linux-vdso.so.1 => (0x00007fff85bfe000) libldap_r-2.4-releng.so.2 => /work/openldap/libraries/libldap_r/.libs/libldap_r-2.4-releng.so.2 (0x00007f3a7d70a000) liblber-2.4-releng.so.2 => /work/openldap/libraries/liblber/.libs/liblber-2.4-releng.so.2 (0x00007f3a7d4f8000) libltdl.so.3 => /usr/lib64/libltdl.so.3 (0x00007f3a7d2f0000) libdb-4.5.so => /usr/lib64/libdb-4.5.so (0x00007f3a7cfb8000) libodbc.so.1 => /usr/lib64/libodbc.so.1 (0x00007f3a7cd4c000) libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f3a7cb30000) libsasl2.so.2 => /usr/lib64/libsasl2.so.2 (0x00007f3a7c915000)
-Dieter
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Nov 14, 2008, at 21:04 , Quanah Gibson-Mount wrote:
Please test RE24.
Currently seeing failure in test019 on Mac OS X 10.5.5 with BDB 4.7.25p1 with the patch ./build/db.4.7.52.patch applied:
Starting test019-syncreplication-cascade ...
running defines.sh Starting master slapd on TCP/IP port 9011... Using ldapsearch to check that master slapd (pid=61712) is running... Using ldapadd to create the context prefix entry in the master... Starting R1 slave slapd on TCP/IP port 9012... Using ldapsearch to check that R1 slave slapd (pid=61717) is running... Starting R2 slave slapd on TCP/IP port 9013... Using ldapsearch to check that R2 slave slapd (pid=61721) is running... Starting P1 slave slapd on TCP/IP port 9014... Using ldapsearch to check that P1 slave slapd (pid=61725) is running... Starting P2 slave slapd on TCP/IP port 9015... Using ldapsearch to check that P2 slave slapd (pid=61729) is running... Starting P3 slave slapd on TCP/IP port 9016... Using ldapsearch to check that P3 slave slapd (pid=61733) is running... Using ldapadd to populate the master directory... Waiting 25 seconds for syncrepl to receive changes... Using ldapmodify to modify master directory... Waiting 25 seconds for syncrepl to receive changes... Using ldapsearch to read all the entries from the master... Using ldapsearch to read all the entries from the R1 slave... Using ldapsearch to read all the entries from the R2 slave... Using ldapsearch to read all the entries from the P1 slave... Using ldapsearch to read all the entries from the P2 slave... Using ldapsearch to read all the entries from the P3 slave... Filtering master ldapsearch results... Filtering R1 slave ldapsearch results... Filtering R2 slave ldapsearch results... Filtering P1 slave ldapsearch results... Filtering P2 slave ldapsearch results... Filtering P3 slave ldapsearch results... Comparing retrieved entries from master and R1 slave... test failed - master and R1 slave databases differ
./scripts/test019-syncreplication-cascade failed (exit 1)
make[2]: *** [bdb-yes] Error 1 make[1]: *** [test] Error 2 make: *** [test] Error 2
A sample difference is here, looks like the last step in the text, the deletion of n=James A Jones 2,ou=Information Technology Division,ou=People,dc=example, has not propagated:
kinky:testrun jens$ diff -rub server1.out server2.out - --- server1.out 2008-11-15 14:27:22.000000000 +0100 +++ server2.out 2008-11-15 14:27:22.000000000 +0100 @@ -318,6 +318,26 @@ sn: Jones entryCSN: 20081115132654.267046Z#000000#000#000000
+dn: cn=James A Jones 2,ou=Information Technology Division,ou=People,dc=example + ,dc=com +objectClass: OpenLDAPperson +cn: James A Jones 2 +cn: James Jones +cn: Jim Jones +sn: Doe +uid: jjones +seeAlso: cn=All Staff,ou=Groups,dc=example,dc=com +homePostalAddress: 933 Brooks $ Anytown, MI 48104 +homePhone: +1 313 555 8838 +title: Senior Manager, Information Technology Division +description: Not around very much +mail: jjones@mailgw.example.com +postalAddress: Info Tech Division $ 535 W William $ Anytown, MI 48103 +pager: +1 313 555 2833 +facsimileTelephoneNumber: +1 313 555 8688 +telephoneNumber: +1 313 555 7334 +entryCSN: 20081115132625.342208Z#000000#000#000000 + dn: cn=Jane Doe,ou=Alumni Association,ou=People,dc=example,dc=com objectClass: OpenLDAPperson cn: Jane Doe
Threw an assertion in the meta tests:
157 assert( !LDAP_BACK_CONN_TAINTED( lc ) );
Full backtrace:
https://www.nbcs.rutgers.edu/~richton/testfail-20081114.txt
(see thread t@8).
Aaron Richton wrote:
Threw an assertion in the meta tests:
157 assert( !LDAP_BACK_CONN_TAINTED( lc ) );
Full backtrace:
Seems to be ITS#5733.
p.
Ing. Pierangelo Masarati OpenLDAP Core Team
SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando@sys-net.it -----------------------------------
Aaron Richton wrote:
On Sat, 15 Nov 2008, Pierangelo Masarati wrote:
Seems to be ITS#5733.
Agreed. Do you think the ITS#5814 changes could help? (Are those scheduled for RE24?)
They should. I only saw that issue once, but was unable to repeat it after the fixes.
p.
Ing. Pierangelo Masarati OpenLDAP Core Team
SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando@sys-net.it -----------------------------------
--On Monday, November 17, 2008 11:32 PM +0100 Pierangelo Masarati ando@sys-net.it wrote:
Aaron Richton wrote:
On Sat, 15 Nov 2008, Pierangelo Masarati wrote:
Seems to be ITS#5733.
Agreed. Do you think the ITS#5814 changes could help? (Are those scheduled for RE24?)
They should. I only saw that issue once, but was unable to repeat it after the fixes.
It's in RE24.
--Quanah
--
Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration
-
Aaron Richton -
Dieter Kluenter -
Howard Chu -
Jens Vagelpohl -
Michael Ströder -
Pierangelo Masarati -
Quanah Gibson-Mount