openldap-bugs

openldap-bugs@openldap.org

1 participants
21518 discussions

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

16 Mar '09

As you methioned, I move ldap_set_option() with NULL to the main thread. And, I also use libldap_r instead of libldap. A specific handler is really only used in a single thread. In every thread, it always returns NULL, because it is just a test code and it always print "connect ok" while it is running. I think memory leak may happen when the code of openLDAP uses openssl function such as initialize connection in ldap_start_tls_s(). For every thread, there may be some special structures for SSL/TLS which need to be freed after the end of the thread. I find that Windows has a function ldap_stop_tls_s() related to ldap_start_tls_s(). For my software, I want to create processes instead of threads to avoid this problem.

1 0

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

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs