[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.