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

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



Pierangelo Masarati wrote:

> ^^^ the problem seems to be rather in libldap; however, despite applying 
> a considerable load to back-ldap, I couldn't see anything like that.  In 
> the meanwhile I fixed a couple more potential leaks in back-ldap, which 
> seem to be totally unrelated (fixed in RE22/HEAD as appropriate).  I 
> will investigate that bit of code in libldap to see if and under what 
> circumstances there's room for a leak (there should be, unless the leak 
> detector you are using is wrong... what software did you use?  I used 
> valgrind).

I used valgrind too. In fact the leak appears only when I interrupt the client.

> >rebind-as-user
> >  
> >
> ^^^ is this relevant?  I mean: does rebind occur during your tests?  It 
> didn't during mine.

No, it doesn't. rebind-as-user will be used for other tests (write tests) that I haven't still done.

> One more comment: that portion of code changed quite a bit from 2.2 to 
> 2.3; can you check if the problem persists with 2.3?

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)
==8742==    by 0x81137CE: wait4msg (result.c:350)
==8742==    by 0x8113229: ldap_result (result.c:122)
==8742==    by 0x80BEE19: ldap_back_search (search.c:251)
==8742==    by 0x805D42F: fe_op_search (search.c:393)
==8742==    by 0x805CC0D: do_search (search.c:223)
==8742==    by 0x805B476: connection_operation (connection.c:1049)
==8742==    by 0x8111F31: ldap_int_thread_pool_wrapper (tpool.c:479)
==8742==    by 0x1BA08D64: thread_wrapper (vg_libpthread.c:886)
==8742==    by 0xB000F5DF: do__quit (vg_scheduler.c:1872)

Raphael Ouazana.