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

[raphael.ouazana@linagora.com]

On Sam 16 juillet 2005 14:52, ando@sys-net.it wrote:
> I built a program that does:
>
> ldap_initialize()
> ldap_sasl_bind()
> ldap_result()
> ldap_search_ext()
> for (;;) {
>     check that ldap_result() == LDAP_RES_SEARCH_ENTRY
> }
>
> If I abort right after ldap_sasl_bind() or right after ldap_search_ext()
> nothing appears; if I abort from inside the ldap_result() loop after
> search, I see the leak you mention with RE22:
>
> ==31263== 24 bytes in 1 blocks are definitely lost in loss record 4 of 14
> ==31263==    at 0x1B9046C1: calloc (vg_replace_malloc.c:176)
> ==31263==    by 0x81A9A1B: ber_memcalloc_x (memory.c:286)
> ==31263==    by 0x8179CE3: try_read1msg (result.c:836)
> ==31263==    by 0x8178F2F: wait4msg (result.c:378)
> ==31263==    by 0x81787C9: ldap_result (result.c:126)
> ==31263==    by 0x80F3E4C: ldap_back_search (search.c:181)
> ==31263==    by 0x80754DF: do_search (search.c:412)
> ==31263==    by 0x80725A0: connection_operation (connection.c:1079)
> ==31263==    by 0x817691B: ldap_int_thread_pool_wrapper (tpool.c:467)
> ==31263==    by 0x1BB299DF: thread_wrapper (vg_libpthread.c:867)
>
> but not with HEAD, nor with 2.3.4; recently some concurrency issue in
> abandon has been fixed in HEAD, I think that very problem might have
> been addressed as well, but not all of those fixes are already in 2.3.4,
> so I'm puzzled I cannot find the leak from 2.3.4 on till HEAD.

I can reproduce the problem with CVS/OPENLDAP_REL_ENG_2_2 of today :
==3690== 192 bytes in 8 blocks are definitely lost in loss record 2 of 6
==3690==    at 0x1B905901: calloc (vg_replace_malloc.c:176)
==3690==    by 0x80F1E5E: ber_memcalloc_x (memory.c:286)
==3690==    by 0x80D3F48: try_read1msg (result.c:836)
==3690==    by 0x80D387E: wait4msg (result.c:378)
==3690==    by 0x80D33B9: ldap_result (result.c:126)
==3690==    by 0x80A99FB: ldap_back_search (search.c:181)
==3690==    by 0x805A3D4: do_search (search.c:412)
==3690==    by 0x8058C31: connection_operation (connection.c:1079)
==3690==    by 0x80D2172: ldap_int_thread_pool_wrapper (tpool.c:467)
==3690==    by 0x1BA08D64: thread_wrapper (vg_libpthread.c:886)
==3690==    by 0xB000F5DF: do__quit (vg_scheduler.c:1872)

Do you want I give you an exact way to reproduce it ?
Note that I use a client with an old library (2.1.30/ubuntu). I don't know
if it can change something...

I can reproduce the other memory leak with 2.3.4 too. Do you want I fill
an other ITS ?

Raphael Ouazana.