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().
changed notes changed state Open to Test moved from Incoming to Software Bugs
changed notes changed state Test to Release
fixed in master fixed in RE25 fixed in RE24
changed notes changed state Release to Closed
head: • 6ccc0974 by Ondřej Kuzník at 2022-01-18T16:46:09+00:00 ITS#8039 Free resinfo even if opcookie is the last owner re26: • c1f4072c by Ondřej Kuzník at 2022-01-18T23:07:06+00:00 ITS#8039 Free resinfo even if opcookie is the last owner re25: • cbc06de6 by Ondřej Kuzník at 2022-01-18T23:07:47+00:00 ITS#8039 Free resinfo even if opcookie is the last owner