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

Re: (ITS#3862) Memory leak in back-ldap



raphael.ouazana@linagora.com wrote:

>Yes, it does. This is the trace for 2.3.4 :
>
>==8742== 1124 bytes in 43 blocks are still reachable in loss record 4 of 7
>==8742==    at 0x1B905901: calloc (vg_replace_malloc.c:176)
>==8742==    by 0x813226E: ber_memcalloc_x (memory.c:286)
>==8742==    by 0x813229D: ber_memcalloc (memory.c:303)
>==8742==    by 0x8130E86: ber_alloc_t (io.c:253)
>==8742==    by 0x81213A7: ldap_alloc_ber_with_options (request.c:72)
>==8742==    by 0x811477D: try_read1msg (result.c:416)
>  
>
^^^ BTW: note that this leak is different from the one you initially 
reported: this is related to a call to ldap_alloc_ber_with_options() 
while the initial one was related to a call to ber_memcalloc_x() 
occurring in the same function but quite few lines later, in a totally 
different context.  I carefully reviewed the code and there seems to be 
no chance of leaking within the try_read1msg() function; it's quite 
likely that the leak occurs somewhere else much later, during the usage 
o the response messages, as a consequence of some very tricky and hardly 
reproducible conditions.

p.


    SysNet - via Dossi,8 27100 Pavia Tel: +390382573859 Fax: +390382476497