[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