(ITS#4839) syncrepl-related tests fail randomly

[ando@sys-net.it]

Full_Name: Pierangelo Masarati
Version: HEAD
OS: irrelevant?
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (81.72.89.40)
Submitted by: ando


I'm seeing occasional failures of syncrepl-related tests in HEAD.  In case of
test043, results differend once, but after repeating the test everything went
smoth.

In some cases test045 resulted in a core dump:

(gdb) bt
#0  0x00418060 in memchr () from /lib/tls/libc.so.6
#1  0x080f5eef in slap_parse_csn_sid (csn=0x87b6798) at ldapsync.c:128
#2  0x080f5fa1 in slap_parse_csn_sids (csns=0x87b6778, numcsns=8)
    at ldapsync.c:148
#3  0x081ce0c6 in syncprov_db_open (be=0x8770bd0) at syncprov.c:2544
#4  0x080f31de in over_db_func (be=0x8770bd0, which=db_open) at backover.c:61
#5  0x080f35dd in over_db_open (be=0x8770bd0) at backover.c:173
#6  0x0808e1d1 in backend_startup_one (be=0x8770bd0) at backend.c:212
#7  0x0808e65e in backend_startup (be=0x8770bd0) at backend.c:303
#8  0x080b578a in slap_startup (be=0x0) at init.c:248
#9  0x08062ee1 in main (argc=8, argv=0xbffa3554) at main.c:919

In this case, numcsns is 8 because syncprov incorrectly tested for
BER_BVISEMPTY() instead of BER_BVISNULL when creating the csn array:

(gdb) p a->a_vals[0]@8
$2 = {{
    bv_len = 40, 
    bv_val = 0x87deb60 "20070210093621.965471Z#000000#000#000000"
  }, {
    bv_len = 7566177, 
    bv_val = 0x0
  }, {
    bv_len = 24, 
    bv_val = 0x11 ""
  }, {
    bv_len = 1820143995, 
    bv_val = 0x706164
"�s����F���\211L$\004\213E\b\211\004$�\037���\205�\211E�\017\204\r����\033���=�\206��tb\213M�\213\001�@\030\002\215v"
  }, {
    bv_len = 541392999, 
    bv_val = 0x21 ""
  }, {
    bv_len = 142432232, 
    bv_val = 0x65 ""
  }, {
    bv_len = 142470176, 
    bv_val = 0x0
  }, {
    bv_len = 142305208, 
    bv_val = 0x0
  }}

Fixing that still results in a test failure, but without core dump:

bash-3.00$ SLAPD_DEBUG=stats ./run test045
Cleaning up test run directory leftover from previous run.
Running ./scripts/test045-syncreplication-proxied...
running defines.sh
Starting master slapd on TCP/IP port 9011...
Using ldapsearch to check that master slapd is running...
Using ldapadd to create the context prefix entry in the master...
Starting slave slapd on TCP/IP port 9012...
Using ldapsearch to check that slave slapd is running...
Starting proxy slapd on TCP/IP port 9013...
Using ldapsearch to check that proxy slapd is running...
1 > Using ldapadd to populate the master directory...
Waiting 15 seconds for syncrepl to receive changes...
1 < Comparing retrieved entries from master and slave...
2 > Stopping the provider, sleeping 10 seconds and restarting it...
Using ldapsearch to check that master slapd is running...
Using ldapmodify to modify master directory...
Waiting 15 seconds for syncrepl to receive changes...
2 < Comparing retrieved entries from master and slave...
test failed - master and slave databases differ

apparently, none of the modifications made it into the consumer.

After another try, things just go smooth again... keep testing.

p.