Full_Name: Howard Chu
Version: 2.4.40
OS: 
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (110.49.207.42)
Submitted by: hyc


In a 3-way MMR setup I'm seeing a consistent leak of queued Entries in syncprov.
I'm not entirely sure of the exact sequence to reproduce it, but this is what I
have so far:

Test DB is 2.5GB on disk. One of the nodes (server #3) is configured with an mdb
maxsize of 1GB, so it will always fail to sync up. The other two have sufficient
maxsize configured.

While server #3 is running, stop server #1 and #2 and completely reinit their
DBs. rm the old files, rerun slapadd -w on server #1 (all new entryUUIDs and
entryCSNs). Start server #1. Server #3 will reconnect and start trying to update
itself and most of the updates will fail (as it runs out of space). Start server
#2 (with an empty DB). It will start syncing from server #1. syncprov leaks will
occur on both #2 and #3 during this time.

Part of the trigger here appears to be from slapadd'ing the DB on server #1
without using the -S <sid> argument, so the DB contents all have SID #0.
In this case updates get sent from #1 to #2 and #3 and syncprov on #2 and
#3ueueues them up for transmission to other nodes, respectively. Syncprov
doesn't know that it doesn't need to do this, because the SID #0 in the updates
doesn't match any of the servers' SID #1, 2, or 3.

The point in the code where the leak occurs is not obvious; the queued entries
are all refcounted and the refcount is incremented whenever an entry is matched
to an outbound queue. The count is decremented when a queue finishes sending the
entry. In this particular case, I don't believe the entry is matched to any
queue, so it should simply be freed again at the end of syncprov_matchops().