[Date Prev][Date Next]
Re: (ITS#6330) slapd memory leak
> --On Friday, October 16, 2009 7:57 AM +0000 email@example.com wrote:
>> firstname.lastname@example.org wrote:
>>> email@example.com wrote:
>>>> Here is the valgrind output. The complete log is at
>>> All 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...
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/