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?