Re: (ITS#5077) syncrepl.add_cmp() infinite loop on swapped values

[donn@u.washington.edu]

On Aug 20, 2007, at 12:32 PM, Howard Chu wrote:

> Donn Cave wrote:
>> On Aug 10, 2007, at 2:16 PM, Howard Chu wrote:
>>> Now fixed in HEAD, please test.
>> Aug 10 15:06:55 rufus03 slapd[31488]: null_callback : error code 0x14
>> Aug 10 15:06:55 rufus03 slapd[31488]: syncrepl_entry: rid=101   
>> be_modify (20)
>> Aug 10 15:06:55 rufus03 slapd[31488]: syncrepl_entry: rid=101   
>> be_modify failed (20)
>> I could put some more research into this, but tell me if this
>> doesn't make sense.  Suppose this mysteriously swapped order:
>>    a,b,...
>>    b,a,...
>> Your fix increments the first list's index, so next iteration it's
>>    b,...
>>    b,a,...
>> which is fine, but next iteration is
>>    ...
>>    a,...
>> "a" looks new at this point, and I try to add it, but it isn't new -
>> we just forgot that it was in "old" - and I get error 0x14
>> (LDAP_TYPE_OR_VALUES_EXISTS)
>
> OK, this should be working now.

No joy here.  Arguably worse - I think you will find that this one
will fail for same-order cases where the original code worked.

1.
      a,b
      x,b
	-> del a, ++i
2.
      b
      x,b
	-> ++i, add x, ++j
3.
      ()
      b
	-> add b (oops, b already present.)

It looks easy enough to me to code up an order independent version that
will actually work.  I would initialize adds[] and dels[] with old & new
berval pointers, iterate through dels[] and adds[] (nested), and clear
both on match.  The code is easier to follow and empirically I see one
fewer matches in the cases I tested it on.  But that's just a test of
the algorithm - I haven't sorted out what needs to be done at the end of
the function where mcur etc. are modified depending on i == j.

	Donn Cave, donn@u.washington.edu