openldap-bugs March 2009

openldap-bugs@openldap.org

48 participants
245 discussions

Re: (ITS#6018) TLS memory leak
by timling2003＠gmail.com 15 Mar '09

15 Mar '09

--000e0cd149d4a04c48046533de2c Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit The sample code is as follows. Make command: g++ testmem.C lib/libldap-2.4.so.2 lib/libsasl2.so.2 lib/liblber-2.4.so.2 -Iinclude/ -Llib/ -DLDAP_DEPRECATED -g -lpthread If mode is normal, it's ok. If mode is TLS, there is memory leak even if you don't input bind dn. If mode is SSL, memory leak only happens when you input bind dn and password. The openLDAP lib is the latest release version 2.4.15. I am sure that this is a bug of openLDAP. #include "ldap.h" #include <string> #include <unistd.h> using namespace std; typedef enum LDAP_TRANS_METHOD {LDAP_TRANS_NORMAL, LDAP_TRANS_TLS, LDAP_TRANS_SSL}; LDAP_TRANS_METHOD transMethod = LDAP_TRANS_NORMAL; const char * host = NULL; const char * binddn = NULL; const char * bindpwd = NULL; int connectnum = 0; void * connectLDAP(void * param) { LDAP * ld; int rc; string url; if( transMethod == LDAP_TRANS_SSL ) url = "ldaps://"; else url = "ldap://"; if( host == NULL ) return NULL; url.append(host); struct timeval tvout; tvout.tv_sec = 10; tvout.tv_usec = 0; if( ldap_set_option( NULL, LDAP_OPT_NETWORK_TIMEOUT, &tvout ) != LDAP_OPT_SUCCESS ) { printf("ldap_set_option LDAP_OPT_NETWORK_TIMEOUT failed\n"); return NULL; } rc = ldap_initialize(&ld, url.c_str()); if( rc != LDAP_SUCCESS || ld == NULL ) { printf("ldap_initialize failed!\n"); return NULL; } if( transMethod == LDAP_TRANS_TLS || transMethod == LDAP_TRANS_SSL ) { int protocol = 3; if( ldap_set_option( ld, LDAP_OPT_PROTOCOL_VERSION, &protocol ) != LDAP_OPT_SUCCESS ) { printf("ldap_set_option LDAP_OPT_PROTOCOL_VERSION failed\n"); return NULL; } int cert = 0; if( ldap_set_option( NULL, LDAP_OPT_X_TLS_REQUIRE_CERT, &cert ) != LDAP_OPT_SUCCESS ) { printf("ldap_set_option LDAP_OPT_X_TLS_REQUIRE_CERT failed\n"); return NULL; } } if( transMethod == LDAP_TRANS_TLS ) { rc = ldap_start_tls_s( ld, NULL, NULL ); if( rc != LDAP_SUCCESS ) { printf("ldap_start_tls_s failed\n"); return NULL; } } if( binddn != NULL && bindpwd != NULL ) { rc = ldap_bind_s(ld, binddn, bindpwd, LDAP_AUTH_SIMPLE); if ( LDAP_SUCCESS != rc ) { printf("ldap_bind_s failed\n"); return NULL; } } ldap_unbind_s(ld); connectnum++; printf("%d connect ok\n", connectnum); return NULL; } int main(int argc, char ** argv) { if(argc < 2) { printf("Usage: testmem <host> [mode] [bind dn] [bind pwd]\n"); printf("mode: default: NORMAL; SSL;TLS\n"); return 0; } string mode="NORMAL"; if( argc > 2 ) mode = argv[2]; if( mode == "SSL" ) transMethod = LDAP_TRANS_SSL; if( mode == "TLS" ) transMethod = LDAP_TRANS_TLS; host = argv[1]; if( argc > 4 ) { binddn = argv[3]; bindpwd = argv[4]; } do { pthread_t instance_thread ; pthread_attr_t attr; pthread_attr_init(&attr); pthread_attr_setdetachstate(&attr, PTHREAD_CREATE_DETACHED); int rc = pthread_create(&instance_thread, &attr, connectLDAP, NULL) ; pthread_attr_destroy(&attr); if (rc) { printf("Fail to create policy server instance thread\n") ; break; } sleep(1); }while(1); return 0; } --000e0cd149d4a04c48046533de2c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable The sample code is as follows. Make command: g++ testmem.C lib/liblda= p-2.4.so.2 lib/libsasl2.so.2 lib/liblber-2.4.so.2 -Iinclude/ -Llib/ -DLDAP_= DEPRECATED -g -lpthread If mode is normal, it's ok. If mode is TLS, = there is memory leak even if you don't input bind dn. If mode is SSL, m= emory leak only happens when you input bind dn and password. The openLDAP lib is the latest release version 2.4.15. I am sure tha= t this is a bug of openLDAP. #include "ldap.h" #include= <string> #include <unistd.h> using namespace std;<br= > typedef enum LDAP_TRANS_METHOD {LDAP_TRANS_NORMAL, LDAP_TRANS_TLS, LDAP= _TRANS_SSL}; LDAP_TRANS_METHOD transMethod =3D LDAP_TRANS_NORMAL;<br= >const char * host =3D NULL; const char * binddn =3D NULL; const char= * bindpwd =3D NULL; int connectnum =3D 0; void * connectLDAP(void * param) { =A0= =A0=A0 LDAP * ld; =A0=A0=A0 =A0 int rc; =A0 string url; =A0 if= ( transMethod =3D=3D LDAP_TRANS_SSL ) =A0=A0=A0=A0=A0 url =3D "ldap= s://"; =A0 else =A0=A0=A0=A0=A0 url =3D "ldap://"; =A0 if( host =3D=3D NULL ) =A0 =A0=A0=A0 return NULL; =A0 url.append(= host); =A0=A0=A0 =A0 struct timeval tvout; =A0 tvout.tv_sec =3D 1= 0; =A0 tvout.tv_usec =3D 0; =A0=A0=A0 if( ldap_set_option( NULL, = LDAP_OPT_NETWORK_TIMEOUT, &tvout ) !=3D LDAP_OPT_SUCCESS ) =A0=A0=A0 { =A0=A0=A0 =A0=A0=A0 printf("ldap_set_option LDAP_OPT_NE= TWORK_TIMEOUT failed\n"); =A0=A0=A0 =A0=A0=A0 return NULL; =A0= =A0=A0 } =A0=A0=A0 =A0 rc =3D ldap_initialize(&ld, url.c_str());= =A0 if( rc !=3D LDAP_SUCCESS || ld =3D=3D NULL ) =A0 { =A0 =A0=A0=A0 printf("ldap_initialize failed!\n"); = =A0=A0=A0 return NULL; =A0 } =A0 if( transMethod =3D=3D LDAP_TRAN= S_TLS || transMethod =3D=3D LDAP_TRANS_SSL ) =A0 { =A0=A0=A0 =A0=A0= =A0 int protocol =3D 3; =A0=A0=A0 if( ldap_set_option( ld, LDAP_OPT_PROT= OCOL_VERSION, &protocol ) !=3D LDAP_OPT_SUCCESS ) =A0=A0=A0 { =A0=A0=A0 =A0=A0=A0 =A0=A0=A0 printf("ldap_set_option L= DAP_OPT_PROTOCOL_VERSION failed\n"); =A0=A0=A0=A0=A0=A0=A0 return N= ULL; =A0=A0=A0 } =A0=A0=A0 int cert =3D 0; =A0=A0=A0 if( ldap_set_= option( NULL, LDAP_OPT_X_TLS_REQUIRE_CERT, &cert ) !=3D LDAP_OPT_SUCCES= S ) =A0=A0=A0 { =A0=A0=A0 =A0=A0=A0 =A0 printf("ldap_set_option LDAP_OP= T_X_TLS_REQUIRE_CERT failed\n"); =A0=A0=A0=A0=A0=A0=A0 return NULL;= =A0=A0=A0 } =A0 } =A0 if( transMethod =3D=3D LDAP_TRANS_TLS )= =A0 { =A0=A0=A0 rc =3D ldap_start_tls_s( ld, NULL, NULL ); =A0=A0=A0 if( rc !=3D LDAP_SUCCESS ) =A0=A0=A0 { =A0=A0=A0 =A0=A0=A0 = =A0 printf("ldap_start_tls_s failed\n"); =A0=A0=A0=A0=A0=A0=A0= return NULL; =A0=A0=A0 } =A0 } =A0=A0=A0 if( binddn !=3D NULL= && bindpwd !=3D NULL ) =A0=A0=A0 { =A0=A0=A0 =A0=A0=A0 rc = =3D ldap_bind_s(ld,=A0 binddn, bindpwd, LDAP_AUTH_SIMPLE); =A0 =A0=A0=A0 if ( LDAP_SUCCESS !=3D rc ) =A0 =A0=A0=A0 { =A0 =A0=A0= =A0 =A0=A0=A0 printf("ldap_bind_s failed\n"); =A0=A0=A0=A0=A0 = return NULL; =A0 =A0=A0=A0 } =A0=A0=A0 } =A0=A0=A0 =A0=A0=A0 l= dap_unbind_s(ld); =A0=A0=A0 connectnum++; =A0=A0=A0 printf("%d c= onnect ok\n", connectnum); =A0=A0=A0 return NULL; } int main(int argc, char ** argv) {<br= >=A0=A0=A0 if(argc < 2) =A0=A0=A0 { =A0=A0=A0 =A0=A0=A0 printf(&qu= ot;Usage: testmem <host> [mode] [bind dn] [bind pwd]\n"); =A0= =A0=A0 =A0=A0=A0 printf("mode: default: NORMAL; SSL;TLS\n"); =A0=A0=A0 =A0=A0=A0 return 0; =A0=A0=A0 } =A0=A0=A0 string mode=3D&qu= ot;NORMAL"; =A0=A0=A0 if( argc > 2 ) =A0=A0=A0 =A0=A0=A0 mode= =3D argv[2]; =A0=A0=A0 if( mode =3D=3D "SSL" ) =A0=A0= =A0 =A0=A0=A0 transMethod =3D LDAP_TRANS_SSL; =A0 if( mode =3D=3D "= TLS" ) =A0=A0=A0 transMethod =3D LDAP_TRANS_TLS; =A0 host =3D argv[1]; =A0 <= br>=A0=A0=A0 if( argc > 4 ) =A0=A0=A0 { =A0 =A0=A0=A0 binddn =3D a= rgv[3]; =A0 =A0=A0=A0 bindpwd =3D argv[4]; =A0=A0=A0=A0 } =A0 = =A0 do =A0 { =A0=A0=A0 pthread_t instance_thread ; =A0 =A0=A0=A0 p= thread_attr_t attr; =A0 =A0=A0=A0 pthread_attr_init(&attr); =A0 =A0=A0=A0 pthread_attr_s= etdetachstate(&attr, PTHREAD_CREATE_DETACHED); =A0 =A0=A0=A0 int rc = =3D pthread_create(&instance_thread, &attr, connectLDAP, NULL) ;<br= >=A0 =A0=A0=A0 pthread_attr_destroy(&attr); =A0=A0=A0 if (rc) =A0=A0=A0 { =A0=A0=A0=A0=A0=A0=A0 printf("Fail= to create policy server instance thread\n") ; =A0=A0=A0=A0=A0=A0= =A0 break; =A0=A0=A0 } =A0=A0=A0 sleep(1); =A0=A0=A0 }while(1);<br= >=A0=A0=A0 return 0; } --000e0cd149d4a04c48046533de2c--

1 0

(ITS#6025) ldapdelete cannot handle base64 encoded dns
by quanah＠OpenLDAP.org 15 Mar '09

15 Mar '09

Full_Name: Quanah Gibson-Mount Version: RE24/HEAD OS: NA URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.111.29.239) As noted in http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=334354 the OpenLDAP ldapdelete utility cannot handle base-64 encoded DNs, even though the other ldap* tools can. It would add to the tool consistency for ldapdelete to conform with the other tools in this respect. --Quanah

1 0

(ITS#6024) Don't send cookie with without csn field
by rein＠OpenLDAP.org 15 Mar '09

15 Mar '09

Full_Name: Rein Tollevik Version: CVS HEAD OS: Irrelevant URL: Submission from: (NULL) (84.215.36.97) Submitted by: rein Syncprov sends a cookie to its consumer even when it doesn't have any csn values, i.e the cookie will only have the rid= and sid= fields. This can happen during initial load (as in test050) when a syncrepl consumer enters the present phase before the provider have finished the refresh phase with its own provider. This doesn't seem to harm the consumer, as it appears to silently ignore these cookies. But it can be confusing for somone trying to analyze the logs.. A fix is coming. Rein Tollevik Basefarm AS

1 0

Re: (ITS#6021) slapo-pcache/back-ldap slapd crashes
by ando＠sys-net.it 14 Mar '09

14 Mar '09

toby(a)inf.ed.ac.uk wrote: > Full_Name: Toby Blake > Version: 2.4.15 > OS: Scientific Linux 5.2 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (129.215.197.95) > > > Hi there, > > I have been testing slapo-pcache/back-ldap for some time now, > typically in student lab situations (to provide a localhost > proxycaching slapd with back-ldap connecting (via gssapi) to several > remote servers), initially using 2.3.x but I have recently moved to > using the latest 2.4.x versions, as it's clear that's where the > development effort is going. > > I'm seeing quite a lot of crashes during my testing, with a few > different backtraces. I don't know whether you would prefer I > submitted these separately for different backtraces, so I'm opening > this ITS to get the process started... > > I have seen no way of reproducing these crashes. > > I'm currently using: > - openldap-2.4.15 on scientific linux 5.2 > - bdb 4.7.25 with 3 patches > - We build our own RPMs. I have openldap-2.4.15 with no optimisation > (-O0) for the purposes of debugging. > > The most common backtrace I see is an assertion failure in > memory.c:152. Here's an example: > > Program terminated with signal 6, Aborted. > #0 0x00b8d402 in __kernel_vsyscall () > (gdb) bt > #0 0x00b8d402 in __kernel_vsyscall () > #1 0x009e8d20 in raise () from /lib/libc.so.6 > #2 0x009ea631 in abort () from /lib/libc.so.6 > #3 0x00a20e6b in __libc_message () from /lib/libc.so.6 > #4 0x00a28b16 in _int_free () from /lib/libc.so.6 > #5 0x00a2c070 in free () from /lib/libc.so.6 > #6 0x081d5746 in ber_memfree_x (p=0xa6809478, ctx=0x0) at memory.c:152 > #7 0x081d630c in ber_bvarray_free_x (a=0x9049bb8, ctx=0x0) at memory.c:731 > #8 0x081d6343 in ber_bvarray_free (a=0x9049bb8) at memory.c:741 > #9 0x08079757 in attr_clean (a=0xb62d41bc) at attr.c:134 The problem seems to be here; apparently, the a->a_nvals array is being incorrectly freed. If you have those core files around, it would be interesting to see the contents of those attributes, e.g. p *a p a->a_desc[0] p a->a_flags p a->a_nvals[0] from within frame 9. > #10 0x0807983b in attrs_free (a=0xb62d41bc) at attr.c:196 > #11 0x0807c059 in entry_clean (e=0xb5acfdbc) at entry.c:504 > #12 0x0811ec17 in ldap_back_search (op=0xa680e5d8, rs=0xb5ad10e0) > at search.c:354 Also, it would be interesting to see the parameters of the search; e.g. p op->o_req_ndn p op->o_request.oq_search p op->o_request.oq_search.rs_filterstr p op->o_request.oq_search.rs_attrs[0] (unless NULL) from within frame 12 > #13 0x080f2b02 in overlay_op_walk (op=0xa680e5d8, rs=0xb5ad10e0, > which=op_search, oi=0x8fa9208, on=0x0) at backover.c:669 > #14 0x080f2d0a in over_op_func (op=0xa680e5d8, rs=0xb5ad10e0, which=op_search) > at backover.c:721 > #15 0x080f2dae in over_op_search (op=0xa680e5d8, rs=0xb5ad10e0) > at backover.c:743 > #16 0x080720d6 in fe_op_search (op=0xa680e5d8, rs=0xb5ad10e0) at search.c:366 > #17 0x08071a2c in do_search (op=0xa680e5d8, rs=0xb5ad10e0) at search.c:217 > #18 0x0806e705 in connection_operation (ctx=0xb5ad11d0, arg_v=0xa680e5d8) > at connection.c:1097 > #19 0x0806ebdf in connection_read_thread (ctx=0xb5ad11d0, argv=0x13) > at connection.c:1223 > #20 0x0819ecad in ldap_int_thread_pool_wrapper (xpool=0x8f86fa0) at tpool.c:663 > #21 0x00b3346b in start_thread () from /lib/libpthread.so.0 > #22 0x00a90dbe in clone () from /lib/libc.so.6 > (gdb) > > I have seen quite a few of these backtraces, although sometimes coming > through slap_sl_free (and a couple of other places) instead of > ber_bvarray_free_x. > > Let me know what further information I can provide. Finally, it would be great to see your slapd.conf. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

[Fwd: RE: (ITS#6019) puzon@eska.pl]
by michael＠stroeder.com 14 Mar '09

14 Mar '09

The stack trace was sent to me personally. :-/ -------- Original Message -------- Subject: RE: (ITS#6019) puzon(a)eska.pl Date: Fri, 13 Mar 2009 15:09:04 +0100 From: Lukasz PUZON Brodowski <puzon(a)eska.pl> To: 'Michael Ströder' <michael(a)stroeder.com> References: <200903121120.n2CBKHqo032649(a)boole.openldap.org> <49B90F15.5070309(a)stroeder.com> Hi Michael Here is gdb: (15:07:44 <~>) 0 # gdb GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-marcel-freebsd". (gdb) file ldapsearch Reading symbols from ldapsearch...(no debugging symbols found)...done. (gdb) run -x -W -D 'cn=Manager,dc=eska' -b "" -s base Starting program: /usr/local/bin/ldapsearch -x -W -D 'cn=Manager,dc=eska' -b "" -s base (no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...Enter LDAP Password: # extended LDIF # # LDAPv3 # base <> with scope baseObject # filter: (objectclass=*) # requesting: ALL # # dn: objectClass: top objectClass: OpenLDAProotDSE # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1 Program received signal SIGSEGV, Segmentation fault. 0x282eb3f0 in free () from /lib/libc.so.7

1 0

Re: (ITS#6022) What is idlcachesize?
by quanah＠zimbra.com 13 Mar '09

13 Mar '09

--On Friday, March 13, 2009 6:47 PM +0000 arun_patel(a)yahoo.com wrote: > Full_Name: Arun Patel > Version: 2.2.13 > OS: linux > URL: > Submission from: (NULL) (135.207.175.192) See the admin guide. Note that question should be sent to an appropriate list. The ITS system is for bug reports. I'd also note that the OpenLDAP 2.2 release is historical. OpenLDAP 2.4 is the current supported release tree. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#6022) What is idlcachesize?
by arun_patel＠yahoo.com 13 Mar '09

13 Mar '09

Full_Name: Arun Patel Version: 2.2.13 OS: linux URL: Submission from: (NULL) (135.207.175.192) Can someone explain to me idlcachesize entry in slapd.conf? What is it used for? Does it optimize? Any and all informatin will be helpful Thanks Arun

1 0

Re: (ITS#5973) Syncrepl can update more than one csn value
by rein＠OpenLDAP.org 13 Mar '09

13 Mar '09

hyc(a)symas.com wrote: > rein(a)OpenLDAP.org wrote: >> Syncrepl can update more than one csn value in one operation, but only one can >> be passed to syncprov in the csn queue. Syncprov should instead pick the >> updated values from the modify operation. > The syncrepl patch broke the CSN queue, which has caused out-of-order updates > in test050. I have reverted it. Every write operation begins with a queued CSN > and ends by graduating a CSN. You removed the enqueueing step, and so the > queue contents were invalid. I removed the queuing and graduating of the CSN syncrepl_updateCookie() would update, as that only sent one of the (possibly) many values that could be updated by that operation. With the syncprov half of the patch the queued patch should never be looked at, meaning that this queuing should be unnecessary here. The ordinary queue/graduation of the CSN received with an updated entry is still in place, and should continue to be so. >> A patch that fixes this is coming. This patch depends on the ITS#5972 patch, >> and is required for the new test058 to succeed. > > test058 has the same number of errors with or without the syncrepl patch, so I > don't think it was relevant to the issues you were addressing. It was only the syncprov half of ITS#5793 patch that was relevant for test058. The syncrepl half of the patch only removes code that should be unnecessary.. > I'm still skeptical about the syncprov half of the patch. The two patches were > actually unrelated, the syncprov patch takes effect regardless of the syncrepl > patch. Yes, the syncprov part of the patch doesn't need the syncrepl half, but I found it correct to clean up code that should be made unnecessary by that patch. All updates received during the persistent phase should include an updated CSN value, and should already have been transmitted to syncprov by the commit/graduate queue and have caused it to update its own csn set. I.e, the syncrepl_updateCookie() replace operation should only have caused syncprov to updated its cookie and thereby send NEW_COOKIE messages when syncrepl updated the CSN set at the end of the refresh phase. Apparently, there is something that causes this to break. More on that in another message on -devel. Rein

1 0

(ITS#6021) slapo-pcache/back-ldap slapd crashes
by toby＠inf.ed.ac.uk 13 Mar '09

13 Mar '09

Full_Name: Toby Blake Version: 2.4.15 OS: Scientific Linux 5.2 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (129.215.197.95) Hi there, I have been testing slapo-pcache/back-ldap for some time now, typically in student lab situations (to provide a localhost proxycaching slapd with back-ldap connecting (via gssapi) to several remote servers), initially using 2.3.x but I have recently moved to using the latest 2.4.x versions, as it's clear that's where the development effort is going. I'm seeing quite a lot of crashes during my testing, with a few different backtraces. I don't know whether you would prefer I submitted these separately for different backtraces, so I'm opening this ITS to get the process started... I have seen no way of reproducing these crashes. I'm currently using: - openldap-2.4.15 on scientific linux 5.2 - bdb 4.7.25 with 3 patches - We build our own RPMs. I have openldap-2.4.15 with no optimisation (-O0) for the purposes of debugging. The most common backtrace I see is an assertion failure in memory.c:152. Here's an example: Program terminated with signal 6, Aborted. #0 0x00b8d402 in __kernel_vsyscall () (gdb) bt #0 0x00b8d402 in __kernel_vsyscall () #1 0x009e8d20 in raise () from /lib/libc.so.6 #2 0x009ea631 in abort () from /lib/libc.so.6 #3 0x00a20e6b in __libc_message () from /lib/libc.so.6 #4 0x00a28b16 in _int_free () from /lib/libc.so.6 #5 0x00a2c070 in free () from /lib/libc.so.6 #6 0x081d5746 in ber_memfree_x (p=0xa6809478, ctx=0x0) at memory.c:152 #7 0x081d630c in ber_bvarray_free_x (a=0x9049bb8, ctx=0x0) at memory.c:731 #8 0x081d6343 in ber_bvarray_free (a=0x9049bb8) at memory.c:741 #9 0x08079757 in attr_clean (a=0xb62d41bc) at attr.c:134 #10 0x0807983b in attrs_free (a=0xb62d41bc) at attr.c:196 #11 0x0807c059 in entry_clean (e=0xb5acfdbc) at entry.c:504 #12 0x0811ec17 in ldap_back_search (op=0xa680e5d8, rs=0xb5ad10e0) at search.c:354 #13 0x080f2b02 in overlay_op_walk (op=0xa680e5d8, rs=0xb5ad10e0, which=op_search, oi=0x8fa9208, on=0x0) at backover.c:669 #14 0x080f2d0a in over_op_func (op=0xa680e5d8, rs=0xb5ad10e0, which=op_search) at backover.c:721 #15 0x080f2dae in over_op_search (op=0xa680e5d8, rs=0xb5ad10e0) at backover.c:743 #16 0x080720d6 in fe_op_search (op=0xa680e5d8, rs=0xb5ad10e0) at search.c:366 #17 0x08071a2c in do_search (op=0xa680e5d8, rs=0xb5ad10e0) at search.c:217 #18 0x0806e705 in connection_operation (ctx=0xb5ad11d0, arg_v=0xa680e5d8) at connection.c:1097 #19 0x0806ebdf in connection_read_thread (ctx=0xb5ad11d0, argv=0x13) at connection.c:1223 #20 0x0819ecad in ldap_int_thread_pool_wrapper (xpool=0x8f86fa0) at tpool.c:663 #21 0x00b3346b in start_thread () from /lib/libpthread.so.0 #22 0x00a90dbe in clone () from /lib/libc.so.6 (gdb) I have seen quite a few of these backtraces, although sometimes coming through slap_sl_free (and a couple of other places) instead of ber_bvarray_free_x. Let me know what further information I can provide. Many thanks Toby Blake School of Informatics University of Edinburgh

1 0

SSL/TLS memory leak in multithread mode. more detail about ITS#6018
by timling2003＠gmail.com 13 Mar '09

13 Mar '09

--000e0cd291e2f684b60464fb3237 Content-Type: multipart/alternative; boundary=000e0cd291e2f6849e0464fb3235 --000e0cd291e2f6849e0464fb3235 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit The program is a daemon which will create a thread to query LDAP server for every request. a part of code of socket loop: newfd = accept(listen_fd, &cliaddr, &clilen); pthread_attr_setdetachstate(&attr, PTHREAD_CREATE_DETACHED); pthread_create(&instance_thread, &attr, queryldap, (void *)newfd); a part of code of querying LDAP server: int queryldap() { timeout = 10 ldap_set_option( NULL, LDAP_OPT_NETWORK_TIMEOUT, &timeout ); if SSL ldap_initialize(&ld, "ldaps://..."); else ldap_initialize(&ld, "ldap://..."); protocol = 3; rc = 0; if SSL or TLS ldap_set_option( ld, LDAP_OPT_PROTOCOL_VERSION, &protocol ); ldap_set_option( NULL, LDAP_OPT_X_TLS_REQUIRE_CERT, &rc ); if TLS ldap_start_tls_s( ld, NULL, NULL ); ldap_bind_s(ld, bindDN, bindPasswd, LDAP_AUTH_SIMPLE); ... ldap_unbind_s(ld); } I cannot use ldap_pvt_tls_destroy(), because this function can call only once. If I don't create different thread for every request (one thread for all request), there is no any memory leak. So, I think this case is related to the multithread mode. Maybe, there are some memory that don't be freed after the querying thread finished. In addtion, there is no any memory leak when I use unencryption mode. The attachment is the snippet of memory image which is likely the leak part. The memory leak produced by one thread seems to be about 352 bytes. --000e0cd291e2f6849e0464fb3235 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable The program is a daemon which will create a thread to query LDAP server for= every request. a part of code of socket loop: newfd =3D accept(= listen_fd, &cliaddr, &clilen); pthread_attr_setdetachstate(&= attr, PTHREAD_CREATE_DETACHED); pthread_create(&instance_thread, &attr, queryldap, (void *)newfd);<= br> a part of code of querying LDAP server: int queryldap() { = =A0=A0=A0 timeout =3D 10 =A0=A0=A0 ldap_set_option( NULL, LDAP_OPT_NETWO= RK_TIMEOUT, &timeout ); =A0=A0=A0 if SSL =A0 =A0=A0 =A0=A0 ldap_initialize(&ld, "ld= aps://..."); =A0=A0=A0 else =A0=A0=A0=A0=A0=A0=A0 ldap_initializ= e(&ld, "ldap://..."); =A0=A0=A0 protocol =3D 3; =A0= =A0=A0 rc =3D 0; =A0=A0=A0 if SSL or TLS =A0=A0=A0=A0=A0=A0=A0 ldap_s= et_option( ld, LDAP_OPT_PROTOCOL_VERSION, &protocol ); =A0 =A0=A0 =A0=A0 ldap_set_option( NULL, LDAP_OPT_X_TLS_REQUIRE_CERT, &= rc ); =A0=A0=A0 if TLS =A0=A0=A0=A0=A0=A0=A0 ldap_start_tls_s( ld= , NULL, NULL ); =A0=A0=A0 ldap_bind_s(ld,=A0 bindDN, bindPasswd, LDA= P_AUTH_SIMPLE); =A0=A0=A0 ... =A0=A0=A0 ldap_unbind_s(ld); } I cannot use ldap_pvt_tls_destroy(= ), because this function can call only once. If I don't create d= ifferent thread for every request (one thread for all request), there is no= any memory leak. So, I think this case is related to the multithread mode.= Maybe, there are some memory that don't be freed after the querying thr= ead finished. In addtion, there is no any memory leak when I use unencry= ption mode. The attachment is the snippet of memory image which is l= ikely the leak part. The memory leak produced by one thread seems to be abo= ut 352 bytes. --000e0cd291e2f6849e0464fb3235-- --000e0cd291e2f684b60464fb3237 Content-Type: application/octet-stream; name=memory-leak-snippet Content-Disposition: attachment; filename=memory-leak-snippet Content-Transfer-Encoding: base64 X-Attachment-Id: f_fs8k4pwa0 AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD///////////////// ////////////////////////////////////////////////////////////////////AAAAAAAA AAARAAAAiDkRCGAMGgh0kgAAUQEAAEkLAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA//// //////////////////////////////////////////////////////////////////////////// /////wAAAAAAAAAAEQAAAOg6EQjADRoItZIAAFEBAABOCwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAP////////////////////////////////////////////////////////////////// //////////////////8AAAAAAAAAABEAAABIPBEIIA8aCPaSAABRAQAAUwsAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAD///////////////////////////////////////////////////// ////////////////////////////////AAAAAAAAAAARAAAAqD0RCIAQGgg3kwAAUQEAAFgLAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA//////////////////////////////////////// /////////////////////////////////////////////wAAAAAAAAAAEQAAAAg/EQjgERoIeJMA AFEBAABdCwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAA= --000e0cd291e2f684b60464fb3237--

1 0

← Newer
1
...
5
6
7
8
9
10
11
...
25
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs March 2009