Hello,

...

Slurpd has a bug when replicating, in the way it generates the LDAPMod array of the add and modify operations : if the same attribute is present several times (for add) or in multiple change blocks (for modify) in the replication log, it simply adds all occurences to the LDAPMod array, hence having one or more attributes repeated serveral times which violates the protocol. [...]

As far as I can see, slurpd merely processes the changes in the replog. If it is generating requests out of sequence, then they must have been recorded out-of-sequence in the log. And yet I don't see any reason why slapd would generate the modifications out of sequence.

That's right for changetype=modify, since the original code aggregates multiple values of the same attributes in a signle LDAPmod if they're given in order in the replog file. But it doesn't do that for changetype=add, which toggled the bug. I choosed to use the same code path for both for simplicity when fixing add.

What are the circumstances that cause these improper sequences to get into the replog in the first place?

In our case, it was just "add" that was problematic. Although I could imagine the replog to be generated by something else than slapd, and I'd expect slurpd to be able to process it as long as it is valid ldif ?

As for copying the code from ldapmodify.c into slurpd - probably the better solution would be to move the relevant code from ldapmodify.c into a library.

Well, the relevant code is about 20 lines long, and adapted to the way slurpd handles memory. But sure, that could be shared.

For the record, the patch I uploaded has an issue with empty changes blocks, so I uploaded a fixed version as ftp://ftp.openldap.org/incoming/gael.roualland-070129.diff