Re: (ITS#6330) slapd memory leak

[hyc@symas.com]

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.txt
>>>
>>> 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/