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?