openldap-bugs March 2009

openldap-bugs@openldap.org

48 participants
245 discussions

Re: (ITS#6027) Debug() accesses free()-d memory in register_at() on error
by ando＠sys-net.it 17 Mar '09

17 Mar '09

test.007(a)seznam.cz wrote: > Full_Name: Test Seven > Version: 2.4.15 > OS: Windows > URL: > Submission from: (NULL) (195.39.55.20) Fixed in HEAD, please test. Thanks, 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

(ITS#6027) Debug() accesses free()-d memory in register_at() on error
by test.007＠seznam.cz 17 Mar '09

17 Mar '09

Full_Name: Test Seven Version: 2.4.15 OS: Windows URL: Submission from: (NULL) (195.39.55.20) http://www.openldap.org/devel/cvsweb.cgi/~checkout~/servers/slapd/at.c?rev=… ldap_attributetype_free( at ); Debug( LDAP_DEBUG_ANY, "register_at: AttributeType \"%s\": %s, %s\n", def, scherr2str(code), err ); You should swap the lines, because ``err'' points inside ``at''. How to reproduce: Compile Debug version with LDAP_DEBUG e.g. with MSVC 2005. Don't configure it slapd.exe -d9 Output: register_at: AttributeType "( OLcfgDbAt:0.1 NAME 'olcDbDirectory' DESC 'Director y for database content' EQUALITY caseIgnoreMatch SYNTAX OMsDirectoryString SINGL E-VALUE )": OID could not be expanded, ŢŢŢŢŢŢŢŢŢŢŢŢŢŢŢŢŢŢ

1 0

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

16 Mar '09

I tested it again and found that there is not memory leak on gcc 4.1.2 and openssl 0.9.8c. The leak version is on gcc 3.3.5 and OpenSSL 0.9.7d. So, it may be not a bug of openLDAP but the other old version software.

1 0

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

16 Mar '09

toby(a)inf.ed.ac.uk wrote: > On 14 Mar 2009, at 15:49, Pierangelo Masarati wrote: > > Hello, > > Thanks for your quick reply. > >>> (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. > > > (gdb) up > #9 0x08079757 in attr_clean (a=0xb62d41bc) at attr.c:134 > 134 ber_bvarray_free( a->a_nvals ); > (gdb) p *a > $1 = {a_desc = 0x8faa150, a_vals = 0x90487f0, a_nvals = 0x9049bb8, > a_numvals = 631, a_flags = 0, a_next = 0x0} > (gdb) p a->a_desc[0] > $2 = {ad_next = 0x0, ad_type = 0x8fbba20, ad_cname = {bv_len = 9, > bv_val = 0x8fba5d8 "memberUid"}, ad_tags = {bv_len = 0, bv_val = > 0x0}, > ad_flags = 0} > (gdb) p a->a_flags > $3 = 0 > (gdb) p a->a_nvals[0] > $4 = {bv_len = 8, bv_val = 0x905aac0 "v1ggoodh"} > (gdb) > > >>> #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 > > > (gdb) up > #12 0x0811ec17 in ldap_back_search (op=0xa680e5d8, rs=0xb5ad10e0) > at search.c:354 > 354 entry_clean( &ent ); > (gdb) p op->o_req_ndn > $5 = {bv_len = 24, bv_val = 0xb44ce1e4 "dc=inf,dc=ed,dc=ac,dc=uk"} > (gdb) p op->o_request.oq_search > $6 = {rs_scope = 2, rs_deref = 0, rs_slimit = 24576, rs_tlimit = 3600, > rs_limit = 0x8fa88b8, rs_attrsonly = 0, rs_attrs = 0xb44ce904, > rs_filter = 0xb44ce86c, rs_filterstr = {bv_len = 112, > bv_val = 0xb44ce87c "(&(objectClass=posixGroup)(| > (memberUid=vlavrenk) > (uniqueMember=uid=vlavrenk,ou=people,dc=inf,dc=ed,dc=ac,dc=uk)))"}} > (gdb) p op->o_request.oq_search.rs_filterstr > $7 = {bv_len = 112, > bv_val = 0xb44ce87c "(&(objectClass=posixGroup)(| > (memberUid=vlavrenk) > (uniqueMember=uid=vlavrenk,ou=people,dc=inf,dc=ed,dc=ac,dc=uk)))"} > (gdb) p op->o_request.oq_search.rs_attrs[0] > $8 = {an_name = {bv_len = 9, bv_val = 0x907b012 "gidNumber"}, > an_desc = 0x8f85930, an_oc_exclude = 0, an_oc = 0x0} > (gdb) > > >> Finally, it would be great to see your slapd.conf. > > > No problem, this is the database, back-ldap, pcache part of it: > > database ldap > suffix dc=inf,dc=ed,dc=ac,dc=uk > rootdn uid=ldaprep/ > hostname.inf.ed.ac.uk,cn=inf.ed.ac.uk,cn=gssapi,cn=auth > uri "ldap://server1.inf.ed.ac.uk/,ldap:// > server2.inf.ed.ac.uk" > idassert-bind mode=none > bindmethod=sasl > saslmech=GSSAPI > idassert-authzFrom "dn:*" > > overlay pcache > > proxycache bdb 5000 4 500 300 > proxycachequeries 10000 > > proxyattrset 0 cn userPassword memberUid uniqueMember > gidNumber > proxyattrset 1 uid userPassword uidNumber gidNumber cn > homeDirectory > loginShell gecos description objectClass afsHomeDirectory primaryRoles > secondary > Roles > proxyattrset 2 cn nisNetgroupTriple memberNisNetgroup > proxyattrset 3 "*" > > proxytemplate (uid=) 1 1800 1800 > proxytemplate (&(objectClass=)(uid=)) 1 1800 1800 > proxytemplate (&(objectClass=)(cn=)) 0 1800 1800 > proxytemplate (&(objectClass=)(cn=)) 2 1800 1800 > proxytemplate (&(objectClass=)(|(memberUid=) > (uniqueMember=))) 0 1800 1800 > proxytemplate (&(objectClass=)(uniqueMember=)) 0 1800 1800 > proxytemplate (&(objectClass=)(memberUid=)) 0 1800 1800 > proxytemplate (&(objectClass=)(uidNumber=)) 1 1800 1800 > proxytemplate (&(objectClass=)(gidNumber=)) 0 1800 1800 > proxytemplate (&(objectClass=)(amdmapName=)(amdmapKey=)) 3 > 1800 1800 > proxytemplate (&(objectClass=)(uid=)) 3 1800 1800 > > directory /var/openldap-data > > checkpoint 128 60 > cachesize 10000 > idlcachesize 10000 > > dbconfig set_cachesize 0 16777216 1 > dbconfig set_lg_regionmax 262144 > dbconfig set_lg_bsize 2097152 > > > If there's anything else that would be useful, let me know. As I > mentioned, I have a number of other core files, including some that > look the same as this one. I did my best to reproduce your setup, but I got no crashes. One thing I'd like to ask is: I see some non-standard attributes in the pcache configuration. Can you tell whether there might occur some schema inconsistencies between the remote server and the proxy? Also, can you tell how often crashes occur, or any detail about the type of operation, the workload and so? I also disabled slab allocation, so that true mallocs occur all times, and valgrind is not showing any memory issue. 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#6021) slapo-pcache/back-ldap slapd crashes
by toby＠inf.ed.ac.uk 16 Mar '09

16 Mar '09

On 14 Mar 2009, at 15:49, Pierangelo Masarati wrote: Hello, Thanks for your quick reply. >> (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. (gdb) up #9 0x08079757 in attr_clean (a=0xb62d41bc) at attr.c:134 134 ber_bvarray_free( a->a_nvals ); (gdb) p *a $1 = {a_desc = 0x8faa150, a_vals = 0x90487f0, a_nvals = 0x9049bb8, a_numvals = 631, a_flags = 0, a_next = 0x0} (gdb) p a->a_desc[0] $2 = {ad_next = 0x0, ad_type = 0x8fbba20, ad_cname = {bv_len = 9, bv_val = 0x8fba5d8 "memberUid"}, ad_tags = {bv_len = 0, bv_val = 0x0}, ad_flags = 0} (gdb) p a->a_flags $3 = 0 (gdb) p a->a_nvals[0] $4 = {bv_len = 8, bv_val = 0x905aac0 "v1ggoodh"} (gdb) >> #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 (gdb) up #12 0x0811ec17 in ldap_back_search (op=0xa680e5d8, rs=0xb5ad10e0) at search.c:354 354 entry_clean( &ent ); (gdb) p op->o_req_ndn $5 = {bv_len = 24, bv_val = 0xb44ce1e4 "dc=inf,dc=ed,dc=ac,dc=uk"} (gdb) p op->o_request.oq_search $6 = {rs_scope = 2, rs_deref = 0, rs_slimit = 24576, rs_tlimit = 3600, rs_limit = 0x8fa88b8, rs_attrsonly = 0, rs_attrs = 0xb44ce904, rs_filter = 0xb44ce86c, rs_filterstr = {bv_len = 112, bv_val = 0xb44ce87c "(&(objectClass=posixGroup)(| (memberUid=vlavrenk) (uniqueMember=uid=vlavrenk,ou=people,dc=inf,dc=ed,dc=ac,dc=uk)))"}} (gdb) p op->o_request.oq_search.rs_filterstr $7 = {bv_len = 112, bv_val = 0xb44ce87c "(&(objectClass=posixGroup)(| (memberUid=vlavrenk) (uniqueMember=uid=vlavrenk,ou=people,dc=inf,dc=ed,dc=ac,dc=uk)))"} (gdb) p op->o_request.oq_search.rs_attrs[0] $8 = {an_name = {bv_len = 9, bv_val = 0x907b012 "gidNumber"}, an_desc = 0x8f85930, an_oc_exclude = 0, an_oc = 0x0} (gdb) > Finally, it would be great to see your slapd.conf. No problem, this is the database, back-ldap, pcache part of it: database ldap suffix dc=inf,dc=ed,dc=ac,dc=uk rootdn uid=ldaprep/ hostname.inf.ed.ac.uk,cn=inf.ed.ac.uk,cn=gssapi,cn=auth uri "ldap://server1.inf.ed.ac.uk/,ldap:// server2.inf.ed.ac.uk" idassert-bind mode=none bindmethod=sasl saslmech=GSSAPI idassert-authzFrom "dn:*" overlay pcache proxycache bdb 5000 4 500 300 proxycachequeries 10000 proxyattrset 0 cn userPassword memberUid uniqueMember gidNumber proxyattrset 1 uid userPassword uidNumber gidNumber cn homeDirectory loginShell gecos description objectClass afsHomeDirectory primaryRoles secondary Roles proxyattrset 2 cn nisNetgroupTriple memberNisNetgroup proxyattrset 3 "*" proxytemplate (uid=) 1 1800 1800 proxytemplate (&(objectClass=)(uid=)) 1 1800 1800 proxytemplate (&(objectClass=)(cn=)) 0 1800 1800 proxytemplate (&(objectClass=)(cn=)) 2 1800 1800 proxytemplate (&(objectClass=)(|(memberUid=) (uniqueMember=))) 0 1800 1800 proxytemplate (&(objectClass=)(uniqueMember=)) 0 1800 1800 proxytemplate (&(objectClass=)(memberUid=)) 0 1800 1800 proxytemplate (&(objectClass=)(uidNumber=)) 1 1800 1800 proxytemplate (&(objectClass=)(gidNumber=)) 0 1800 1800 proxytemplate (&(objectClass=)(amdmapName=)(amdmapKey=)) 3 1800 1800 proxytemplate (&(objectClass=)(uid=)) 3 1800 1800 directory /var/openldap-data checkpoint 128 60 cachesize 10000 idlcachesize 10000 dbconfig set_cachesize 0 16777216 1 dbconfig set_lg_regionmax 262144 dbconfig set_lg_bsize 2097152 If there's anything else that would be useful, let me know. As I mentioned, I have a number of other core files, including some that look the same as this one. Cheers Toby -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336.

1 0

ITS#6019
by puzon＠eska.pl 16 Mar '09

16 Mar '09

(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

(ITS#6026) Don't run autosaved test scripts
by rein＠OpenLDAP.org 16 Mar '09

16 Mar '09

Full_Name: Rein Tollevik Version: CVS HEAD OS: Irrelevant URL: Submission from: (NULL) (81.93.160.250) Submitted by: rein When running the entire test suite it happily includes autosaved versions of the test scripts. Which can be a bit annoying if the scripts are edited with an editor that loves to leave autosave files around.. A fix is coming. Rein Tollevik Basefarm AS

1 0

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

← Newer
1
...
4
5
6
7
8
9
10
...
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