[Date Prev][Date Next] [Chronological] [Thread] [Top]

RE: password policy module memory leaks / excessive replication?





--On May 13, 2014 at 2:21:03 PM -0700 Quanah Gibson-Mount <quanah@zimbra.com> wrote:


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?

No, s_sid in the syncops struct in syncprov.c.  That is what was flipping
from [1|2|3] -> 0 on my systems.

For example, here's what I saw on a problematic master:

(gdb) print *so
$1 = {s_next = 0x0, s_base = {bv_len = 12, bv_val = 0xa857d70 "cn=accesslog"}, s_eid = 1, s_op = 0xc13a300, s_rid = 0, s_sid = 0, s_filterstr = {bv_len = 46, bv_val = 0x42ca1f8 ""}, s_flags = 34, s_inuse = 2, s_res = 0x0, s_restail = 0x0, s_mutex = {__data = {__lock = 0, __count = 0, __owner = 0, __nusers = 0, __kind = 0, __spins = 0, __list = {__prev = 0x0, __next = 0x0}}, __size = '\000' <repeats 39 times>,

We can see here that s_sid = 0 instead of 2  (The server ID of this master)

The other issue here is that it has also lots the rid (s_rid=0). We use rids of 100 and up in my configurations. So you can watch on both of those, and see what triggers first.

--Quanah


--
Quanah Gibson-Mount
Server Architect
Zimbra, Inc
--------------------
Zimbra ::  the leader in open source messaging and collaboration