- openldap-bugs - openldap.org

Re: (ITS#6018) TLS memory leak
by hyc＠symas.com 16 Mar '09

16 Mar '09

ando(a)sys-net.it wrote: > I see at least two issues in your code. See below for specific comments. The code also fails to compile for me because struct timeval is undefined. Having fixed that, valgrind shows no leaks for me. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#6018) TLS memory leak
by ando＠sys-net.it 16 Mar '09

16 Mar '09

I see at least two issues in your code. See below for specific comments. ling qing wrote: > 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 ) You're not supposed to call ldap_set_option() with NULL handler from within a threaded program, as libldap is thread-safe only when a specific handler is only used from within a single thread. I'm not discussing the case of this specific option, nor of its side-effects, if any, as I didn't investigate it and I'm not specifically familiar with that portion of code. > { > 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; > } > } This code is filled with "return NULL;" without cleaning up memory if anything goes wrong. Are you sure everything is always going fine for all your threads during your tests? > > 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; > } > 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

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

(ITS#6020) MMR sends too many redundant messages
by hyc＠OpenLDAP.org 12 Mar '09

12 Mar '09

Full_Name: Howard Chu Version: HEAD/RE24 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (76.91.220.157) Submitted by: hyc Currently syncprov knows not to send a change back to the originating server, but it will still send changes back to the server that delivered it. (E.g., server 1 replicates to server 2, server 2 to server 3. Server 3 will immediately try to send the same message back to server 2.) Syncrepl isn't providing any information for syncprov to know where a change came from. The fix is for syncrepl to attach the incoming sync_cookie state to the operation it uses when writing to its own database. Coming in HEAD shortly.

1 0

Re: (ITS#6019) puzon@eska.pl
by michael＠stroeder.com 12 Mar '09

12 Mar '09

puzon(a)eska.pl wrote: > Full_Name: Lukasz Brodowski > Version: 2.4.15 > OS: freebsd 7.1 > URL: > Submission from: (NULL) (62.29.173.121) > > > Command like this: 'ldapsearch -x -D "cn=Manager,dc=example" -H > ldap://ldap.example -W' ends segmentation fault 11 (core dumped), when I send > correct password. I use this on several machines and effect is the same. Can you obtain a stack trace with gdb and the core file? See here how to obtain it: http://www.openldap.org/faq/data/cache/59.html Ciao, Michael.

1 0

Re: (ITS#5973) Syncrepl can update more than one csn value
by hyc＠symas.com 12 Mar '09

12 Mar '09

rein(a)OpenLDAP.org wrote: > Full_Name: Rein Tollevik > Version: CVS HEAD > OS: irrelevant > URL: > Submission from: (NULL) (81.93.160.250) > Submitted by: rein > > > Syncrepl can update more than one csn value in one operation, False. An operation can only affect one entry. An entry has only one CSN (entryCSN is single-valued). Multiple changes may have occurred to an entry before a consumer sees it, but the consumer will only see the final result and only the last entryCSN. On the other hand, multiple CSNs may have changed in the cookie that is transmitted to the consumer. That's a separate issue... > but only one can > be passed to syncprov in the csn queue. > Syncprov should instead pick the > updated values from the modify operation. > > A patch that fixes this is coming. This patch depends on the ITS#5972 patch, > and is required for the new test058 to succeed. > > Rein Tollevik > Basefarm AS > > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#5973) Syncrepl can update more than one csn value
by hyc＠symas.com 12 Mar '09

12 Mar '09

rein(a)OpenLDAP.org wrote: > Full_Name: Rein Tollevik > Version: CVS HEAD > OS: irrelevant > URL: > Submission from: (NULL) (81.93.160.250) > Submitted by: rein > > > 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. > 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. 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. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#6015) ldapsearch can not retrieve same uid that has been added after it was deleted
by michael＠stroeder.com 12 Mar '09

12 Mar '09

arun_patel(a)yahoo.com wrote: > Version: 2.2.13 In general: This is a *very* ancient release. Also there's no information about the underlying Berkeley-DB and the database backend used in your setup. It's very unlikely that anybody can help you track issues down with this setup. > 6) ldapsearch -LLL -x -b uid=tesid,xyz.com > unable to retrieve the testid (Problem) > > I know the testid is in ldap, because went thru ldap browser and did see the > entry. > [..] > I then did /etc/init.d/ldap stop and /etc/init.d/ldap start > > After entering ldapsearch -LLL -x -b uid=tesid,xyz.com, it works, > > Why does this happen? Not much information about your setup. You should provide more details (e.g. database backend used, indexing and ACLs in slapd.conf). Preferrably discuss your setup on the openldap-software mailing list. Ciao, Michael.

1 0

Re: (ITS#6012) segmentation fault triggered with slapcat
by martin.konold＠erfrakon.de 12 Mar '09

12 Mar '09

Am Dienstag, 10. März 2009 06:53:34 schrieben Sie: > Please provide steps to reproduce the segfault, thanks. Hi Howard, I tried to reproduce the problem on either OpenSUSE 11.1 or Fedora but I could not reproduce the crash. The crash was reproducable with OpenPKG though I guess the crash depends on the version of bdb beeing used. The code fetches an transaction from an internal table which might have slightly different semantics with regards to initialization depending on bdb version. Anyway if you look at the rather trivial patch you will see that it indeed solves a problem independent of bdb version used so the code does not depend on a side effect anymore. On one hand the void pointer *data should not be dangeling and therefore initialization with NULL is correct. On the other hand TXN_ABORT() must not be called with potentially dangeling pointers and therefor a trivial check for the validitiy of the pointer is a good idea. Yours, --martin -- e r f r a k o n Erlewein, Frank, Konold & Partner - Beratende Ingenieure und Physiker Sitz: Adolfstraße 23, 70469 Stuttgart, Partnerschaftsregister Stuttgart PR 126 http://www.erfrakon.com/

1 0

(ITS#6019) puzon@eska.pl
by puzon＠eska.pl 12 Mar '09

12 Mar '09

Full_Name: Lukasz Brodowski Version: 2.4.15 OS: freebsd 7.1 URL: Submission from: (NULL) (62.29.173.121) Command like this: 'ldapsearch -x -D "cn=Manager,dc=example" -H ldap://ldap.example -W' ends segmentation fault 11 (core dumped), when I send correct password. I use this on several machines and effect is the same.

1 0

Re: (ITS#6018) TLS memory leak
by ando＠sys-net.it 12 Mar '09

12 Mar '09

timling2003(a)gmail.com wrote: > I have checked it on openldap-2.4.15. But, it still has this problem. > btw, I use cyrus-sasl-2.1.22.tar.gz for building. We cannot assume there's a bug in OpenLDAP code only because your code triggers an unexpected behavior, without seeing your code entirely. The simple fact that your code calls fairly common OpenLDAP functions that appear to behave correctly when used by other software seems to indicate that there is no issue with those functions. 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

Re: (ITS#6014) rev. 1.121 of clients/tools/common.c makes ldapmodify coredump
by ando＠sys-net.it 12 Mar '09

12 Mar '09

d(a)delphij.net wrote: > Here is a patch that intends to fix #6014. getpassphrase() (which in > turn would be a getpass() call, or lutil_getpass() call), returns a > pointer from a static char * pointer, which should never be free()'ed. > Therefore, a strdup() should be called. > > Note that, since both getpass() implementation could return NULL, we can > not strdup() directly. Instead, we need to detect whether it's NULL and > handle separately. Probably, a better solution would be to implement a lutil_get_terminal_password(char *prompt, struct berval *passwd) routine that mallocs as appropriate. 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

Re: (ITS#6015) ldapsearch can not retrieve same uid that has been added after it was deleted
by Pierangelo Masarati 12 Mar '09

12 Mar '09

Please direct software usage questions to openldap-software(a)openldap.org. Also, note that 2.2.13 is ancient. You should upgrade to 2.4.15. This ITS will be closed. p.

1 0

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

12 Mar '09

--000e0cd1af8ce900de0464e92621 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit OpenSSL version is 0.9.7d 17 Mar 2004. I will create a connect to LDAP server( windows active directory on windows server 2003) for every query request. Then, I will unbind this connect. 2009/3/12 ling qing <timling2003(a)gmail.com> > I have checked it on openldap-2.4.15. But, it still has this problem. > btw, I use cyrus-sasl-2.1.22.tar.gz for building. > thanks > > 2009/3/12 Pierangelo Masarati <openldap-its(a)openldap.org> > >> 2.3.32 is obsolete. It's pointless to debug it. Please check whether the >> problem persists in 2.4.15. >> >> p. >> > > --000e0cd1af8ce900de0464e92621 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable OpenSSL version is 0.9.7d 17 Mar 2004. I will create a connect to LDAP s= erver( windows active directory on windows server 2003) for every query req= uest. Then, I will unbind this connect. <div class=3D"gmail_quote"> 2009/3/12 ling qing <<a href=3D"mailto:timling2003@gma= il.com">timling2003(a)gmail.com</a>> <blockquote class=3D"gmail_= quote" style=3D"border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt = 0pt 0.8ex; padding-left: 1ex;"> I have checked it on openldap-2.4.15. But, it still has this problem. bt= w, I use cyrus-sasl-2.1.22.tar.gz for building. thanks <div class= =3D"gmail_quote">2009/3/12 Pierangelo Masarati <<a hre= f=3D"mailto:openldap-its@openldap.org" target=3D"_blank">openldap-its@openl= dap.org</a>><div class=3D"im"> <blockquote class=3D"gmail_quote" style=3D"border-left: 1px solid rgb(204, = 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">2.3.32 is obsolet= e. =A0It's pointless to debug it. =A0Please check whether the problem persists in 2.4.15. p. </blockquote></div></div> </blockquote></div> --000e0cd1af8ce900de0464e92621--

1 0

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

12 Mar '09

--000e0cd292782d513d0464e91168 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I have checked it on openldap-2.4.15. But, it still has this problem. btw, I use cyrus-sasl-2.1.22.tar.gz for building. thanks 2009/3/12 Pierangelo Masarati <openldap-its(a)openldap.org> > 2.3.32 is obsolete. It's pointless to debug it. Please check whether the > problem persists in 2.4.15. > > p. > --000e0cd292782d513d0464e91168 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I have checked it on openldap-2.4.15. But, it still has this problem. bt= w, I use cyrus-sasl-2.1.22.tar.gz for building. thanks <div class= =3D"gmail_quote">2009/3/12 Pierangelo Masarati <<a hre= f=3D"mailto:openldap-its@openldap.org">openldap-its(a)openldap.org</a>></s= pan> <blockquote class=3D"gmail_quote" style=3D"border-left: 1px solid rgb(204, = 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">2.3.32 is obsolet= e. =A0It's pointless to debug it. =A0Please check whether the problem persists in 2.4.15. p. </blockquote></div> --000e0cd292782d513d0464e91168--

1 0

Re: (ITS#6017) Implement parentGUID or similar in OpenLDAP
by ando＠sys-net.it 12 Mar '09

12 Mar '09

abartlet(a)samba.org wrote: > I found the formal spec in MS-ADTS: > > It currently reads: > > 3.1.1.4.5.28 parentGUID > This attribute is not present on an object that is the root of an NC. > For all other objects, let TO be > the object from which the parentGUID attribute is being read and let > TP be TO!parent. > TO!parentGUID is equal to TP!objectGUID. Sounds like a nightmare of internal searches if we want to generate it on the fly (although possibly acceptable by those queries that require it). It might be worth to consider storing it in directory, and track add/rename operations accordingly. The overlay that implements it should also provide a tool hook for bi_tool_entry_put. 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

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs