quanah@zimbra.com wrote:
--On Friday, October 16, 2009 7:57 AM +0000 masarati@aero.polimi.it wrote:
hyc@symas.com wrote:
whm@stanford.edu wrote:
Here is the valgrind output. The complete log is at
http://www.stanford.edu/~whm/files/slapd/valgrind-memcheck.txtAll of this indicates memory leaks and errors in the SASL library, not any bug in OpenLDAP.
That was exactly my suspect when you originally stated that the leak only appeared after wrapping dynlist requests within a SASL bind/unbind. The leak could still be related to an improper use of SASL library calls by OpenLDAP, although unlikely. However, that valgrind output does not help as leaks related to malloc are too hidden into SASL; you should add --num-callers=<more than 12, the default; enough to see something related to OpenLDAP's code>.
Given that the memory issue is not seen with OpenLDAP 2.3 + dyngroup, I'd still have to agree there's something wrong with what OpenLDAP 2.4 + dynlist is doing.
Merely increasing --num-callers isn't going to be sufficient to track this. Since valgrind only reports leaks after a program exits, and the Cyrus SASL library unloads the offending plugin before it exits, most of the stack trace will be missing any useful symbols. You'll have to run a modified libsasl2.so that omits its dlclose() calls so that the libgssapiv2 plugin will remain loaded, so that its symbols will still be accessible when slapd exits.
Also, since the trace only shows leaks triggered from sasl_client_step and sasl_server_step, which are only executed during SASL Bind processing, you ought to be able to duplicate these leaks regardless of dynlist or any other overlays, since the leaks are occurring before any of these overlays have even started to run.
Of course, if you're unable to reproduce these leaks with dynlist out of the picture, then I guess the finger points into dynlist again...