(ITS#3459) Selective replication producing extra blank lines that break replication

[bryan@wann.net]

Full_Name: Bryan Wann
Version: 2.1.29-1
OS: Linux Fedora Core 2 - 2.6.8-1.521
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (216.166.58.68)


I use a 2.1 server to replicate out to 2.0 servers.  In slapd.conf under
'replica' I have "attr!=entryCSN,entryUUID,modifiersName,modifyTimestamp"
configured to withhold attributes from my 2.0 servers.  The problem I'm seeing
only appears when there's more than one replica configured and only when doing
"add: objectClass" operations.

After the "add: objectClass" data is written, there is a series of modifies to
update entryCSN, modifiersName, modifyTimestamp.  When these attributes are
withheld from replicas, there is still something writing a '\n' to the
replication log in place of the withheld replicated data for each instance of
replica.

For example, if you have four replicas with "attr!" configured, there are four
'\n' being written out to the replication log:

==========
time: 1104447088
dn: cn=bryan,ou=People,o=wann
changetype: modify
replace: entryCSN
entryCSN: 2004123022:51:28Z#0x0002#0#0000
-
replace: modifiersName
modifiersName: cn=admin,o=wann
-
replace: modifyTimestamp
modifyTimestamp: 20041230225128Z
-

   [four blank lines here]


==========

Slurpd will correctly read in this replication log, send the "add: objectClass"
to it's slaves.  However, anything after the extra blank lines slurpd will not
process.    For all operations afterward, slurpd debugging shows it's aware
there's new data in slapd's master log and will append this to slurpd.replog. 
After that, the only way to get slurpd to continue replicating is to remove the
extra blank lines from the replog.

I /think/ the culprit is in servers/slapd/repl.c in replog1() or print_vals().

I have looked through ITS and I haven't found anything that seems to
specifically acknowledge this problem.  ITS #2889 sounds like it may be vaguely
related, but I'm not sure.