RE: password policy module memory leaks / excessive replication?

["Paul B. Henson" <henson@acm.org>]

> From: Quanah Gibson-Mount
> Sent: Monday, May 12, 2014 7:00 PM
>
> I haven't had any luck in reproducing it in my lab.  I'd be curious to
know
> if you could share your cn=config setup (minus rootdn passwords), and
> describe how you are triggering the ppolicy updates in the lab.

I'll send you my config off list. The first time this happened, I had
enabled the password policy module and configured two policies, one as
default, and one explicitly configured on about a dozen service accounts. I
played with that for about an hour until I realized the authentication
failure granularity was insufficient to meet our account lockout needs. Then
it just sat basically idle, and maybe 6-8 hours later it started ramping up
memory use and blew up. The second time, I reloaded our dev environment with
a snapshot of production data, and started it up with the password policy
module loaded, but no actual password policies defined. Once again, within a
few hours it started spinning. I'll see if I can get some minimal
configuration that reliably reproduces this failure, I don't think our ISO
would be on board with shipping you a copy of our production data :).

> If you're up to gdb debugging, then the first step is to gdb slapd, and
set
> a watchpoint on the serverID, so you can see at which point it gets set to
> '0' instead of the the correct sid value.

My current binaries don't have debugging symbols, but I will build a binary
with debugging enabled and give it a try if I get the time. So you mean the
slap_serverID variable defined in servers/slapd/ctxcsn.c?