I am sorry for posting a follow up after a long time.
Did you solve this problem ? What version of the C-SDK were you using ?
I am using C-SDK 5.0 for my client and the process size is constantly
increasing, looks like a memory leak. I have checked my part of the code and
also made sure that the results coming in are all freed.
Thanks
Ram

William M. Perry wrote in message <899nb5$[EMAIL PROTECTED]>...
>[EMAIL PROTECTED] (William M. Perry) writes:
>
>> In using the C SDK (from source) with the memcache bug hand-patched,
>> Insure++ reports a memory leak coming from nsldapi_post_result when doing
>> asynch searches... this happens even though I know that every
ldap_result()
>> matches up with an ldap_msgfree() call.  It reports the leak (20 bytes)
>> coming from:
>>
>> nsldap_calloc() open.c:351
>> nsldapi_post_result result.c:1152
>> [...]
>> nsldapi_result_nolock result.c:174
>> ldap_result() result.c:88
>>
>> Has anybody else seen this?  I have verified with tracing printf()s that
>> every LDAPMessage * retrieved by ldap_result(ld,msg,1,...) does end up
>> going thru ldap_msgfree().
>>
>> This happens with and without the use of the memory cache.
>>
>> Please CC replies - I'll try to check the newsgroup frequently, but... :)
>
>Some more information... it looks like the `LDAPPend' structure that is
>message-id specific is never freed.  I've verified this by stepping through
>the code and by adding appropriate print statements.  unlink_pend() is
>never even called!
>
>If anybody groks the code better than I, please let me know.  I'll keep
>digging.
>
>-Bill P.



Reply via email to