Full_Name: Arthur de Jong Version: 2.4.23 OS: Debian URL: Submission from: (NULL) (2001:888:1613:0:218:8bff:fe55:2c9f) There seems to be a memory leak in the LDAP client library when casing referrals. When the code below is run through valgrind it reports: ==30395== 4,184 (80 direct, 4,104 indirect) bytes in 1 blocks are definitely lost in loss record 3 of 3 ==30395== at 0x402328F: calloc (vg_replace_malloc.c:467) ==30395== by 0x41D2CDF: ber_memcalloc_x (in /usr/lib/liblber-2.4.so.2.5.6) ==30395== by 0x40650A0: ldap_send_server_request (in /usr/lib/libldap_r-2.4.so.2.5.6) ==30395== by 0x4065EB1: ldap_chase_v3referrals (in /usr/lib/libldap_r-2.4.so.2.5.6) ==30395== by 0x40510A3: ldap_result (in /usr/lib/libldap_r-2.4.so.2.5.6) ==30395== by 0x8048871: main (test.c:28) The code below is not very pretty (does not include error handling) but should free all returned buffers. I can also reproduce the above leak with the ldapsearch command-line tool. Some background: http://www.openldap.org/lists/openldap-technical/201012/msg00031.html http://lists.arthurdejong.org/nss-pam-ldapd-users/2010/msg00166.html -----8<-- test.c --8<----- #include <stdio.h> #include <errno.h> #define LDAP_DEPRECATED 1 #include <ldap.h> int main(int argc,char *argv[]) { char *base="dc=test,dc=tld"; char *filter="(objectClass=posixAccount)"; char *attrs[] = { "uid", NULL }; int i; LDAP *ld; LDAPMessage *msg=NULL; int msgid; char **values; /* set up connection */ ldap_initialize(&ld,"ldap://localhost";); i=3; ldap_set_option(ld,LDAP_OPT_PROTOCOL_VERSION,&i); ldap_simple_bind_s(ld,NULL,NULL); /* start search and handle results */ ldap_search_ext(ld,base,LDAP_SCOPE_SUB,filter,attrs, 0,NULL,NULL,NULL,LDAP_NO_LIMIT,&msgid); while (1) { switch (ldap_result(ld,msgid,LDAP_MSG_ONE,NULL,&msg)) { case LDAP_RES_SEARCH_ENTRY: /* we have a normal search entry, print some attribute values */ values=ldap_get_values(ld,msg,attrs[0]); for (i=0;values[i]!=NULL;i++) fprintf(stderr,"%s=%s\n",attrs[0],values[i]); ldap_value_free(values); break; case LDAP_RES_SEARCH_RESULT: /* end of results */ ldap_msgfree(msg); ldap_unbind(ld); return 0; case LDAP_RES_SEARCH_REFERENCE: break; /* just ignore search references */ default: /* we have some error condition, bail out */ return -1; } ldap_msgfree(msg); } } -----8<-- test.c --8<-----
changed notes changed state Open to Test moved from Incoming to Software Bugs
arthur@arthurdejong.org wrote: > Full_Name: Arthur de Jong > Version: 2.4.23 > OS: Debian > URL: > Submission from: (NULL) (2001:888:1613:0:218:8bff:fe55:2c9f) > > > There seems to be a memory leak in the LDAP client library when casing > referrals. When the code below is run through valgrind it reports: > > ==30395== 4,184 (80 direct, 4,104 indirect) bytes in 1 blocks are definitely > lost in loss record 3 of 3 > ==30395== at 0x402328F: calloc (vg_replace_malloc.c:467) > ==30395== by 0x41D2CDF: ber_memcalloc_x (in /usr/lib/liblber-2.4.so.2.5.6) > ==30395== by 0x40650A0: ldap_send_server_request (in > /usr/lib/libldap_r-2.4.so.2.5.6) > ==30395== by 0x4065EB1: ldap_chase_v3referrals (in > /usr/lib/libldap_r-2.4.so.2.5.6) > ==30395== by 0x40510A3: ldap_result (in /usr/lib/libldap_r-2.4.so.2.5.6) > ==30395== by 0x8048871: main (test.c:28) > > The code below is not very pretty (does not include error handling) but should > free all returned buffers. I can also reproduce the above leak with the > ldapsearch command-line tool. Thanks, reproduced using ldapsearch. Fixed in HEAD. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
On Fri, 2010-12-10 at 19:52 -0800, Howard Chu wrote: > Thanks, reproduced using ldapsearch. Fixed in HEAD. Thanks for the quick response and fix! -- -- arthur - arthur@arthurdejong.org - http://arthurdejong.org --
changed notes changed state Test to Release
changed notes changed state Release to Closed
fixed in HEAD fixed in RE24