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

[ando@sys-net.it]

raphael.ouazana@linagora.com wrote:

>Full_Name: Raphael Ouazana
>Version: 2.2.27
>OS: Linux/Ubuntu 5.04
>URL: ftp://ftp.openldap.org/incoming/
>Submission from: (NULL) (82.224.39.128)
>
>
>
>I got a little memory leak trying to load (10 threads doing 1 bind, 2 search, 1
>unbind) a proxy:
>
>==8396== 48 bytes in 2 blocks are definitely lost in loss record 2 of 6
>==8396==    at 0x1B905901: calloc (vg_replace_malloc.c:176)
>==8396==    by 0x80F1D3E: ber_memcalloc_x (memory.c:286)
>==8396==    by 0x80D3E28: try_read1msg (result.c:836)
>  
>
^^^ 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).

>==8396==    by 0x80D375E: wait4msg (result.c:378)
>==8396==    by 0x80D3299: ldap_result (result.c:126)
>==8396==    by 0x80A997B: ldap_back_search (search.c:181)
>==8396==    by 0x805A3D4: do_search (search.c:412)
>==8396==    by 0x8058C31: connection_operation (connection.c:1079)
>==8396==    by 0x80D2052: ldap_int_thread_pool_wrapper (tpool.c:467)
>==8396==    by 0x1BA08D64: thread_wrapper (vg_libpthread.c:886)
>==8396==    by 0xB000F5DF: do__quit (vg_scheduler.c:1872)
>
>My (very simple) configuration file:
>
>---
>include         [...]/core.schema
>pidfile         [...]/slapd.pid
>argsfile        [...]/slapd.args
>database        ldap
>suffix          "dc=my-domain,dc=com"
>lastmod         off
>rebind-as-user
>  
>
^^^ is this relevant?  I mean: does rebind occur during your tests?  It 
didn't during mine.

p.


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