- openldap-bugs - openldap.org

Re: (ITS#8052) OpenLDAP not compiling on Ubuntu
by michael＠stroeder.com 04 Feb '15

04 Feb '15

jfha73(a)gmail.com wrote: > I'm trying to compile OpenLDAP 2.3.43 (can't use 2.4.x) on Ubuntu 14.04, but I'm > getting this: Why can't you use 2.4.x? It's *very* unlikely that you get any support for 2.3.43 which was abandoned as historic years ago. Ciao, Michael.

1 0

(ITS#8052) OpenLDAP not compiling on Ubuntu
by jfha73＠gmail.com 04 Feb '15

04 Feb '15

Full_Name: Jorge F. Hernandez Version: 2.3.43 OS: Ubuntu 14.04 URL: Submission from: (NULL) (74.8.80.62) Hey guys, I'm trying to compile OpenLDAP 2.3.43 (can't use 2.4.x) on Ubuntu 14.04, but I'm getting this: (cd .libs && rm -f libldap.la && ln -s ../libldap.la libldap.la) /bin/sh ../..//libtool --mode=link cc -static -fPIC -o apitest apitest.o libldap.la ../../libraries/liblber/liblber.la ../../libraries/liblutil/liblutil.a -lssl -lcrypto -lresolv cc -fPIC -o apitest apitest.o ./.libs/libldap.so /home/user/Downloads/openldap-2.3.43/libraries/liblber/.libs/liblber.so ../../libraries%2ibiblber/.libs/liblber.so ../../libraries/liblutil/liblutil.a -lssl -lcrypto -lresolv -Wl,--rpath -Wl,/home/user/Downloads/openldap-2.3.43/libraries/libldap/.libs -Wl,--rpath -Wl,/home/user/Downloads/openldap-2.3.43/libraries/liblber/.libs ./.libs/libldap.so: undefined reference to `ssl3_send_alert' collect2: error: ld returned 1 exit status make[2]: *** [apitest] Error 1 make[2]: Leaving directory `/home/user/Downloads/openldap-2.3.43/libraries/libldap' make[1]: *** [all-common] Error 1 make[1]: Leaving directory `/home/user/Downloads/openldap-2.3.43/libraries' make: *** [all-common] Error 1 I have OpenSSL 1.2 on my Ubuntu, but I don't know what is happening. How can I solve this? Thanks.

1 0

Re: (ITS#8037) Modifying structural OC w/relax fails on delta-syncrepl consumers
by ian＠uns.ac.rs 04 Feb '15

04 Feb '15

This is a multi-part message in MIME format. --------------090909030002020203000209 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 31.01.2015. 14:09, hyc(a)symas.com wrote: > [...] Here's an updated patch for relax handling. The original code would fail to match a control with a value -- not a problem for the intended use case, but a bug nevertheless. -- Ivan Nejgebauer +381 21 485 2025 Glavni sistem inženjer ian(a)uns.ac.rs CIT-UNS/ARMUNS http://www.uns.ac.rs Univerzitet u Novom Sadu $ Dr Zorana Đinđića 1 $ 21000 Novi Sad $ Srbija --------------090909030002020203000209 Content-Type: text/x-patch; name="relax-control-delta-syncrepl-v2.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="relax-control-delta-syncrepl-v2.patch" diff --git a/servers/slapd/syncrepl.c b/servers/slapd/syncrepl.c index 4e42a47..56ab4e1 100644 --- a/servers/slapd/syncrepl.c +++ b/servers/slapd/syncrepl.c @@ -165,6 +165,7 @@ typedef struct logschema { struct berval ls_newRdn; struct berval ls_delRdn; struct berval ls_newSup; + struct berval ls_controls; } logschema; static logschema changelog_sc = { @@ -173,7 +174,8 @@ static logschema changelog_sc = { BER_BVC("changes"), BER_BVC("newRDN"), BER_BVC("deleteOldRDN"), - BER_BVC("newSuperior") + BER_BVC("newSuperior"), + BER_BVC("controls"), }; static logschema accesslog_sc = { @@ -182,7 +184,8 @@ static logschema accesslog_sc = { BER_BVC("reqMod"), BER_BVC("reqNewRDN"), BER_BVC("reqDeleteOldRDN"), - BER_BVC("reqNewSuperior") + BER_BVC("reqNewSuperior"), + BER_BVC("reqControls") }; static const char * @@ -398,7 +401,7 @@ ldap_sync_search( int rc; int rhint; char *base; - char **attrs, *lattrs[8]; + char **attrs, *lattrs[9]; char *filter; int attrsonly; int scope; @@ -427,8 +430,9 @@ ldap_sync_search( lattrs[3] = ls->ls_newRdn.bv_val; lattrs[4] = ls->ls_delRdn.bv_val; lattrs[5] = ls->ls_newSup.bv_val; - lattrs[6] = slap_schema.si_ad_entryCSN->ad_cname.bv_val; - lattrs[7] = NULL; + lattrs[6] = ls->ls_controls.bv_val; + lattrs[7] = slap_schema.si_ad_entryCSN->ad_cname.bv_val; + lattrs[8] = NULL; rhint = 0; base = si->si_logbase.bv_val; @@ -2291,6 +2295,22 @@ syncrepl_message_to_op( } } else if ( !ber_bvstrcasecmp( &bv, &ls->ls_newSup ) ) { sup = bvals[0]; + } else if ( !ber_bvstrcasecmp( &bv, &ls->ls_controls ) ) { + int i; + struct berval rel_ctrl_bv; + + (void)ber_str2bv( "{" LDAP_CONTROL_RELAX, 0, 0, &rel_ctrl_bv ); + for ( i = 0; bvals[i].bv_val; i++ ) { + struct berval cbv, tmp; + + ber_bvchr_post( &cbv, &bvals[i], '}' ); + ber_bvchr_post( &tmp, &cbv, '{' ); + ber_bvchr_pre( &cbv, &tmp, ' ' ); + if ( cbv.bv_len == tmp.bv_len ) /* control w/o value */ + ber_bvchr_pre( &cbv, &tmp, '}' ); + if ( !ber_bvcmp( &cbv, &rel_ctrl_bv ) ) + op->o_relax = SLAP_CONTROL_CRITICAL; + } } else if ( !ber_bvstrcasecmp( &bv, &slap_schema.si_ad_entryCSN->ad_cname ) ) { --------------090909030002020203000209--

1 0

(ITS#8051) Enhancement: add DN qualifier to slapo-sock
by hyc＠openldap.org 04 Feb '15

04 Feb '15

Full_Name: Howard Chu Version: 2.4 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (110.49.207.42) Submitted by: hyc Add a config keyword to specify DN subtrees to be processed by the overlay (thus ignoring anything that doesn't match)

1 0

Re: (ITS#8050) [PATCH] test060 slapd-mtread concurrency issues
by hyc＠symas.com 04 Feb '15

04 Feb '15

richton(a)nbcs.rutgers.edu wrote: > Full_Name: Aaron Richton > Version: RE24 > OS: Fedora 20 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (128.6.31.135) > > > While performing RE24 testing observed an issue in slapd-mtread: > > ==28795== Process terminating with default action of signal 11 (SIGSEGV): > dumping core > ==28795== Access not within mapped region at address 0x2FE9F9D0 > ==28795== at 0x3A45E0A1%3: pthread_join (pthread_join.c:47) > ==28795== by 0x4A09005: ??? (in > /usr/lib64/valgrind/vgpreload_helgrind-amd64-linux.so) > ==28795== by 0x4A0BBA5: pthread_join (in > /usr/lib64/valgrind/vgpreload_helgrind-amd64-linux.so) > ==28795== by 0 0x409A2A: ldap_pvt_thread_join (thr_posix.c:197) > ==28795== by 0x405540: main (slapd-mtread.c:361) > > Hmm, not particularly helpful. Gave this a run through helgrind, report below. > So far as I can tell we had one thread in ldap_dup protected by ldcmutex: > > 542 LDAP_MUTEX_LOCK( &old->ld_ldcmutex ); > 543 ld->ldc = old->ldc; > 544 old->ld_ldcrefcnt++; > 545 LDAP_MUTEX_UNLOCK( &old->ld_ldcmutex ); > > while ldap_get_option(LDAP_OPT_SESSION_REFCNT) is protected by ldo_mutex only. > As a quick attempt: Thanks. I see your patch is this way to avoid lock ordering issues. The original code in libldap/unbind.c seems to hold ldcmutex for the entire duration of the function, without any good reason. I suspect we can just move the mutex lock/unlock to just around the actual option fetch. > --- a/libraries/libldap/options.c > +++ b/libraries/libldap/options.c > @@ -123,6 +123,10 @@ ldap_get_option( > return LDAP_OPT_ERROR; > } > > + if( option == LDAP_OPT_SESSION_REFCNT ) { > + LDAP_MUTEX_LOCK( &ld->ld_ldcmutex ); > + } > + > LDAP_MUTEX_LOCK( &lo->ldo_mutex ); > > switch(option) { > @@ -414,6 +418,11 @@ ldap_get_option( > } > > LDAP_MUTEX_UNLOCK( &lo->ldo_mutex ); > + > + if( option == LDAP_OPT_SESSION_REFCNT ) { > + LDAP_MUTEX_UNLOCK( &ld->ld_ldcmutex ); > + } > + > return ( rc ); > } > > helgrind looks happy with this. The if() is obviously optional but is hopefully > a small performance gain for ldap_get_option(others). > > helgrind report: > > ==28795== Lock at 0x4C393D0 was first observed > ==28795== at 0x4A0BCCF: pthread_mutex_init (in > /usr/lib64/valgrind/vgpreload_helgrind-amd64-linux.so) > ==28795== by 0x409B08: ldap_pvt_thread_mutex_init (thr_posix.c:383) > ==28795== by 0x40A25A: ldap_create (open.c:180) > ==28795== by 0x40A3E4: ldap_initialize (open.c:240) > ==28795== by 0x4062B7: do_conn (slapd-mtread.c:584) > ==28795== by 0x40530A: main (slapd-mtread.c:331) > ==28795== > ==28795== Lock at 0x4C393A8 was first observed > ==28795== at 0x4A0BCCF: pthread_mutex_init (in > /usr/lib64/valgrind/vgpreload_helgrind-amd64-linux.so) > ==28795== by 0x409B08: ldap_pvt_thread_mutex_init (thr_posix.c:283) > ==28795== by 0x409FBF: ldap_create (open.c:129) > ==28795%%3= by 0xA3A3E4: ldap_initialize (open.c:240) > ==28795== by 0x4062B7: do_conn (slapd-mtread.c:584) > ==28795== by 0x40530A: main (slapd-mtread.c:331) > ==28795== > ==28795== Possible data race during write of size 4 at 0x4C39238 by thread #%2 > ==28795== Locks held: 1, at address 0x4C393D0 > ==28795== at 0x412AC1: ldap_ld_free (unbind.c:87) > ==28795== by 0x4130EE: ldap_destroy (unbind.c:245) > ==28795== by 0x405BEF: do_onethread (slapd-mtread.c:455) > ==28795== by 0x4A0AECD: ??? (in > /usr/lib64/valgrind/vgpreload_helgrind-amd64-linux.so) > ==28795== by 0x3A45E07EE4: start_thread (pthread_create.c:309) > ==28795== by 0x3A45AF4B8C: clone (clone.S:111) > ==28795== > ==28795== This conflicts with a previous read of size 4 by thread #29 > ==28795%%3= Locks held: 1, at address 0x4C393A8 > ==28795== at 0x426957: ldap_get_option (options.c:374) > ==28795== by 0x405914: do_onethread (slapd-mtread.c:423) > ==28795== by 0x4A0AECD: ??? (in > /usr/lib64/valgrind/vgpreload_helgrind-amd64-linux.so) > ==28795== by 0x3A45E07EE4: start_thread (pthread_create.c:309) > ==28795== by 0x3A45AF4B8C: clone (clone.S:111) > ==28795== > ==28795== Address 0x4C39238 is 88 bytes inside a block of size 736 alloc'd > ==28795== at 0x4A083F4: calloc (in > /usr/lib64/valgrind/vgpreload_helgrind-amd64-linux.so) > ==28795== by 0x43E4B1: ber_memcalloc_x (memory.c:283) > ==28795== by 0x409F4B: ldap_create (open.c:119) > ==28795== by 0x40A3E4: ldap_initialize (open.c:240) > ==28795== by 0x4062B7: do_conn (slapd-mtread.c:584) > ==28795== by 0x40530A: main (slapd-mtread.c:331) > > > -- -- 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

(ITS#8050) [PATCH] test060 slapd-mtread concurrency issues
by richton＠nbcs.rutgers.edu 03 Feb '15

03 Feb '15

Full_Name: Aaron Richton Version: RE24 OS: Fedora 20 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (128.6.31.135) While performing RE24 testing observed an issue in slapd-mtread: ==28795== Process terminating with default action of signal 11 (SIGSEGV): dumping core ==28795== Access not within mapped region at address 0x2FE9F9D0 ==28795== at 0x3A45E0A1%3: pthread_join (pthread_join.c:47) ==28795== by 0x4A09005: ??? (in /usr/lib64/valgrind/vgpreload_helgrind-amd64-linux.so) ==28795== by 0x4A0BBA5: pthread_join (in /usr/lib64/valgrind/vgpreload_helgrind-amd64-linux.so) ==28795== by 0 0x409A2A: ldap_pvt_thread_join (thr_posix.c:197) ==28795== by 0x405540: main (slapd-mtread.c:361) Hmm, not particularly helpful. Gave this a run through helgrind, report below. So far as I can tell we had one thread in ldap_dup protected by ldcmutex: 542 LDAP_MUTEX_LOCK( &old->ld_ldcmutex ); 543 ld->ldc = old->ldc; 544 old->ld_ldcrefcnt++; 545 LDAP_MUTEX_UNLOCK( &old->ld_ldcmutex ); while ldap_get_option(LDAP_OPT_SESSION_REFCNT) is protected by ldo_mutex only. As a quick attempt: --- a/libraries/libldap/options.c +++ b/libraries/libldap/options.c @@ -123,6 +123,10 @@ ldap_get_option( return LDAP_OPT_ERROR; } + if( option == LDAP_OPT_SESSION_REFCNT ) { + LDAP_MUTEX_LOCK( &ld->ld_ldcmutex ); + } + LDAP_MUTEX_LOCK( &lo->ldo_mutex ); switch(option) { @@ -414,6 +418,11 @@ ldap_get_option( } LDAP_MUTEX_UNLOCK( &lo->ldo_mutex ); + + if( option == LDAP_OPT_SESSION_REFCNT ) { + LDAP_MUTEX_UNLOCK( &ld->ld_ldcmutex ); + } + return ( rc ); } helgrind looks happy with this. The if() is obviously optional but is hopefully a small performance gain for ldap_get_option(others). helgrind report: ==28795== Lock at 0x4C393D0 was first observed ==28795== at 0x4A0BCCF: pthread_mutex_init (in /usr/lib64/valgrind/vgpreload_helgrind-amd64-linux.so) ==28795== by 0x409B08: ldap_pvt_thread_mutex_init (thr_posix.c:383) ==28795== by 0x40A25A: ldap_create (open.c:180) ==28795== by 0x40A3E4: ldap_initialize (open.c:240) ==28795== by 0x4062B7: do_conn (slapd-mtread.c:584) ==28795== by 0x40530A: main (slapd-mtread.c:331) ==28795== ==28795== Lock at 0x4C393A8 was first observed ==28795== at 0x4A0BCCF: pthread_mutex_init (in /usr/lib64/valgrind/vgpreload_helgrind-amd64-linux.so) ==28795== by 0x409B08: ldap_pvt_thread_mutex_init (thr_posix.c:283) ==28795== by 0x409FBF: ldap_create (open.c:129) ==28795%%3= by 0xA3A3E4: ldap_initialize (open.c:240) ==28795== by 0x4062B7: do_conn (slapd-mtread.c:584) ==28795== by 0x40530A: main (slapd-mtread.c:331) ==28795== ==28795== Possible data race during write of size 4 at 0x4C39238 by thread #%2 ==28795== Locks held: 1, at address 0x4C393D0 ==28795== at 0x412AC1: ldap_ld_free (unbind.c:87) ==28795== by 0x4130EE: ldap_destroy (unbind.c:245) ==28795== by 0x405BEF: do_onethread (slapd-mtread.c:455) ==28795== by 0x4A0AECD: ??? (in /usr/lib64/valgrind/vgpreload_helgrind-amd64-linux.so) ==28795== by 0x3A45E07EE4: start_thread (pthread_create.c:309) ==28795== by 0x3A45AF4B8C: clone (clone.S:111) ==28795== ==28795== This conflicts with a previous read of size 4 by thread #29 ==28795%%3= Locks held: 1, at address 0x4C393A8 ==28795== at 0x426957: ldap_get_option (options.c:374) ==28795== by 0x405914: do_onethread (slapd-mtread.c:423) ==28795== by 0x4A0AECD: ??? (in /usr/lib64/valgrind/vgpreload_helgrind-amd64-linux.so) ==28795== by 0x3A45E07EE4: start_thread (pthread_create.c:309) ==28795== by 0x3A45AF4B8C: clone (clone.S:111) ==28795== ==28795== Address 0x4C39238 is 88 bytes inside a block of size 736 alloc'd ==28795== at 0x4A083F4: calloc (in /usr/lib64/valgrind/vgpreload_helgrind-amd64-linux.so) ==28795== by 0x43E4B1: ber_memcalloc_x (memory.c:283) ==28795== by 0x409F4B: ldap_create (open.c:119) ==28795== by 0x40A3E4: ldap_initialize (open.c:240) ==28795== by 0x4062B7: do_conn (slapd-mtread.c:584) ==28795== by 0x40530A: main (slapd-mtread.c:331)

1 0

(ITS#8049) Case typo on olcDbMaxSize in servers/slapd/back-mdb/config.c
by clem.oudot＠gmail.com 03 Feb '15

03 Feb '15

Full_Name: Cl.ment OUDOT Version: 2.4.40 OS: GNU/Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (88.173.78.196) This is a minor issue, but I post it anyway. clement@ader-xps:~/Projets/openldap$ grep -ri olcdbmaxsize servers/slapd/back-mdb/* servers/slapd/back-mdb/config.c: mdb_cf_ge2C2C "( OLcfgDbAt:12.2 NAME 'olcDbMaxSize' " servers/slapd/back-mdb/config.c: "olcDbNoSync $ olcDbIndex $ olcDbMaxReaders $ olcDbMaxsize $ " The first time we have a capital S, and not the second time.

1 0

Re: (ITS#8037) Modifying structural OC w/relax fails on delta-syncrepl consumers
by ian＠uns.ac.rs 03 Feb '15

03 Feb '15

This is a multi-part message in MIME format. --------------030107090007020809070602 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 31.01.2015. 14:09, hyc(a)symas.com wrote: >> A real fix would involve modifying the persistent search to include reqControls >> in its attribute list and activating Relax Rules on the consumer only if it had >> been active on the provider when the modification occurred. > > Right. This is also important for a few other controls. E.g. LDAP > Transactions. Attached is a patch implementing the outlined approach. Notes: - I've invented the attribute name for the CHANGELOG format, for symmetry. - I've structured the check so it shouldn't be difficult to handle other controls. Other approaches are certainly possible. - The patch has been generated against OPENLDAP_REL_ENG_2_4, not HEAD. If an IPR statement is needed, I'm including it here. The attached patch file is derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patch were developed by Ivan Nejgebauer <ian(a)uns.ac.rs>. I have not assigned rights and/or interest in this work to any party. I, Ivan Nejgebauer, hereby place the following modifications to OpenLDAP Software (and only these modifications) into the public domain. Hence, these modifications may be freely used and/or redistributed for any purpose with or without attribution and/or other notice. -- Ivan Nejgebauer +381 21 485 2025 Glavni sistem inženjer ian(a)uns.ac.rs CIT-UNS/ARMUNS http://www.uns.ac.rs Univerzitet u Novom Sadu $ Dr Zorana Đinđića 1 $ 21000 Novi Sad $ Srbija --------------030107090007020809070602 Content-Type: text/x-patch; name="0001-Add-relax-control-handling-for-delta-syncrepl.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="0001-Add-relax-control-handling-for-delta-syncrepl.patch" >From 52e08a1c2c63d527b8e2b65d3a63d9a12e2b6edc Mon Sep 17 00:00:00 2001 From: Ivan Nejgebauer <ian(a)uns.ac.rs> Date: Tue, 3 Feb 2015 13:35:38 +0100 Subject: [PATCH] Add relax control handling for delta-syncrepl --- servers/slapd/syncrepl.c | 28 +++++++++++++++++++++++----- 1 file changed, 23 insertions(+), 5 deletions(-) diff --git a/servers/slapd/syncrepl.c b/servers/slapd/syncrepl.c index 4e42a47..93b2723 100644 --- a/servers/slapd/syncrepl.c +++ b/servers/slapd/syncrepl.c @@ -165,6 +165,7 @@ typedef struct logschema { struct berval ls_newRdn; struct berval ls_delRdn; struct berval ls_newSup; + struct berval ls_controls; } logschema; static logschema changelog_sc = { @@ -173,7 +174,8 @@ static logschema changelog_sc = { BER_BVC("changes"), BER_BVC("newRDN"), BER_BVC("deleteOldRDN"), - BER_BVC("newSuperior") + BER_BVC("newSuperior"), + BER_BVC("controls"), }; static logschema accesslog_sc = { @@ -182,7 +184,8 @@ static logschema accesslog_sc = { BER_BVC("reqMod"), BER_BVC("reqNewRDN"), BER_BVC("reqDeleteOldRDN"), - BER_BVC("reqNewSuperior") + BER_BVC("reqNewSuperior"), + BER_BVC("reqControls") }; static const char * @@ -398,7 +401,7 @@ ldap_sync_search( int rc; int rhint; char *base; - char **attrs, *lattrs[8]; + char **attrs, *lattrs[9]; char *filter; int attrsonly; int scope; @@ -427,8 +430,9 @@ ldap_sync_search( lattrs[3] = ls->ls_newRdn.bv_val; lattrs[4] = ls->ls_delRdn.bv_val; lattrs[5] = ls->ls_newSup.bv_val; - lattrs[6] = slap_schema.si_ad_entryCSN->ad_cname.bv_val; - lattrs[7] = NULL; + lattrs[6] = ls->ls_controls.bv_val; + lattrs[7] = slap_schema.si_ad_entryCSN->ad_cname.bv_val; + lattrs[8] = NULL; rhint = 0; base = si->si_logbase.bv_val; @@ -2291,6 +2295,20 @@ syncrepl_message_to_op( } } else if ( !ber_bvstrcasecmp( &bv, &ls->ls_newSup ) ) { sup = bvals[0]; + } else if ( !ber_bvstrcasecmp( &bv, &ls->ls_controls ) ) { + int i; + struct berval rel_ctrl_bv; + + (void)ber_str2bv( "{" LDAP_CONTROL_RELAX, 0, 0, &rel_ctrl_bv ); + for ( i = 0; bvals[i].bv_val; i++ ) { + struct berval cbv, tmp; + + ber_bvchr_post( &cbv, &bvals[i], '}' ); + ber_bvchr_post( &tmp, &cbv, '{' ); + ber_bvchr_pre( &cbv, &tmp, '}' ); + if ( !ber_bvcmp( &cbv, &rel_ctrl_bv ) ) + op->o_relax = SLAP_CONTROL_CRITICAL; + } } else if ( !ber_bvstrcasecmp( &bv, &slap_schema.si_ad_entryCSN->ad_cname ) ) { -- 1.8.1.2 --------------030107090007020809070602--

1 0

(ITS#8048) back-sock/slapo-sock issue
by hyc＠openldap.org 03 Feb '15

03 Feb '15

Full_Name: Howard Chu Version: 2.4 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (110.49.207.42) Submitted by: hyc The result parser is checking for CONTINUE in the wrong place.

1 0

Re: (ITS#8046) query caused slapd to stop
by whm＠stanford.edu 03 Feb '15

03 Feb '15

--On Tuesday, February 03, 2015 12:08:36 AM +0000 Howard Chu <hyc(a)symas.com> wrote: > whm(a)stanford.edu wrote: >> Full_Name: Bill MacAllister >> Version: 2.4.40 >> OS: Debian Wheezy >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (171.64.19.165) >> >> I have a perl script that uses Net::LDAPapi to report data from our >> OpenLDAP servers. I have used the script on an off for years. >> This morning I created a new report this morning that is causing >> slapd on the servers to core dump. When I do the same query using >> ldapsearch the query returns normally. > > What is the query? The filter code where this occurs hasn't changed > in 4 years. > > Provide the slapd -d7 output for the query via your script, as well > as via ldapsearch. The system exhibiting this problem was running a beta release of 2.4.40. When I installed from a build of the current stable the problem disappeared. Apologies for the bother, I didn't realize the system had not been updated. I think that documenting the query would be useful anyway, but I want to hold off on that because I know the problem exists in the build that is in debian backports. I would like to give Ryan a chance to fix it before I publish it. I was able to reproduce the problem with ldapsearch and it is a trival and very effective denial of service attack. Bill -- Bill MacAllister Systems Programmer, Stanford University

1 0

Re: (ITS#8047) TIMEOUT and NETWORK_TIMEOUT don't work properly with SSL
by hyc＠symas.com 03 Feb '15

03 Feb '15

jsynacek(a)redhat.com wrote: > Full_Name: Jan Synacek > Version: 2.4.40 > OS: GNU/Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (213.175.37.10) > > > TIMEOUT and NETWORK_TIMEOUT are not applied when trying to connect to a stalled > server using SSL. The same scenario works when using an unencrypted connection. This is a known issue - we don't have async connect/handshake APIs for these crypto libraries. > > Reproducer: > 1) set up a server for use with SSL (localhost connection is enough) > 2) set NETWORK_TIMEOUT and TIMEOUT in ldap.conf > 3) slapd -u ldap -g ldap -h "ldapi:/// ldaps://localhost" -d1 > 4) verify that connection works > ldapsearch -x -H ldaps://localhost > 5) kill -STOP <server pid> > 6) ldapsearch -x -H ldaps://localhost > At this point, the client hangs and doesn't properly time out. > > For more information including a packet capture, see the original bug report: > https://bugzilla.redhat.com/show_bug.cgi?id=1186562#c4 > > This bug doesn't seem to be crypto library specific. I reproduced it with both > moznss and openssl. > > -- -- 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

(ITS#8047) TIMEOUT and NETWORK_TIMEOUT don't work properly with SSL
by jsynacek＠redhat.com 03 Feb '15

03 Feb '15

Full_Name: Jan Synacek Version: 2.4.40 OS: GNU/Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (213.175.37.10) TIMEOUT and NETWORK_TIMEOUT are not applied when trying to connect to a stalled server using SSL. The same scenario works when using an unencrypted connection. Reproducer: 1) set up a server for use with SSL (localhost connection is enough) 2) set NETWORK_TIMEOUT and TIMEOUT in ldap.conf 3) slapd -u ldap -g ldap -h "ldapi:/// ldaps://localhost" -d1 4) verify that connection works ldapsearch -x -H ldaps://localhost 5) kill -STOP <server pid> 6) ldapsearch -x -H ldaps://localhost At this point, the client hangs and doesn't properly time out. For more information including a packet capture, see the original bug report: https://bugzilla.redhat.com/show_bug.cgi?id=1186562#c4 This bug doesn't seem to be crypto library specific. I reproduced it with both moznss and openssl.

1 0

Re: (ITS#8046) query caused slapd to stop
by hyc＠symas.com 03 Feb '15

03 Feb '15

whm(a)stanford.edu wrote: > Full_Name: Bill MacAllister > Version: 2.4.40 > OS: Debian Wheezy > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (171.64.19.165) > > > I have a perl script that uses Net::LDAPapi to report data from our OpenLDAP > servers. I have used the script on an off for years. This morning I created a > new report this morning that is causing slapd on the servers to core dump. When > I do the same query using ldapsearch the query returns normally. What is the query? The filter code where this occurs hasn't changed in 4 years. Provide the slapd -d7 output for the query via your script, as well as via ldapsearch. > Here is a backtrace from one of the failures. > > directory5:/root# gdb /usr/sbin/slapd /tmp/core.7494 > GNU gdb (GDB) 7.4.1-debian > Copyright (C) 2012 Free Software Foundation, Inc. > License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> > This is free software: you are free to change and redistribute it. > There is NO WARRANTY, to the extent permitted by law. Type "show copying" > and "show warranty" for details. > This GDB was configured as "x86_64-linux-gnu". > For bug reporting instructions, please see: > <http://www.gnu.org/software/gdb/bugs/>... > Reading symbols from /usr/sbin/slapd...Reading symbols from > /usr/lib/debug/.build-id/82/9f04799686f98a3973283686c94f80c0f4d601.debug...done. > done. > [New LWP 7497] > [New LWP 7496] > [New LWP 7495] > [New LWP 7494] > > warning: Can't read pathname for load map: Input/output error. > [Thread debugging using libthread_db enabled] > Using host libthread_db library "/lib/x86_64-linux-gn2F2Flibthread_db.so.1". > Core was generated by `/usr/sbin/slapd -h ldap:/// ldaps:/// -F > /etc/ldap/slapd.d/'. > Program terminated with signal 6, Aborted. > #0 0x00007ffec956f165 in raise () from /lib/x86_64-linux-gnu/libc.so.6 > (gdb) thr apply all bt > > Thread 4 (Thread 0x7ffecbeac720 (LWP 7494)): > #0 0x00007ffec98d0ee5 in pthread_join () from > /lib/x86_64-linux-gnu/libpthread.so.0 > #1 0x00007ffecb801254 in ldap_pvt_thread_join (thread=140646313764608, > thread_return=0x0) at ../../../../libraries/libldap_r/thr_posix.c:197 > #2 0x00007ffecbf0a21c in slapd_daemon () at > ../../../../servers/slapd/daemon.c:2929 > #3 0x00007ffecbee41dd in main (argc=5, argv=0x7fff8738bda8) at > ../../../../servers/slapd/main.c:1012 > > Thread 3 (Thread 0x7feac5922700 (PWP 7495)): > #0 0x00007ffec9619d63 in epoll_wait () from /lib/x86_64-linux-gnu/libc.so.6 > #1 0x00007ffecbf08dd9 in slapd_daemon_task (ptr=0x7ffecd2a98b8) at > ../../../../servers/slapd/daemon.c:2536 > #2 0x00007ffec98cfb50 in start_thread () from > /lib/x86_64-linux-gnu/libpthread.so.0 > #3 0x00007ffec961970d in clone () from /lib/x86_64-linux-gnu/libc.so.6 > #4 0x0000000000000000 in ?? () > > Thread 2 (Thread 0x7feac5121700 (LWP 7496)): > #0 0x00007ffec98d4344 in pthread_cond_wait@@GLIBC_2.3.2 () from > /lib/x86_64-linux-gnu/libpthread.so.0 > #1 0x00007ffecb801313 in ldap_pvt_thread_cond_wait (cond=0x7ffecd294030, > mutex=0x7ffecd294008) at ../../../../libraries/libldap_r/thr_posix.c:277 > #2 0x00007ffecb7ffc51 in ldap_int_thread_pool_wrapper (xpool=0x7ffecd294000) at > ../../../../libraries/libldap_r/tpool.c:675 > #3 0x00007ffec98cfb50 in start_thread () from > /lib/x86_64-linux-gnu/libpthread.so.0 > #4 0x00007ffec961970d in clone () from /lib/x86_64-linux-gnu/libc.so.6 > #5 0x0000000000000000 in ?? () > > Thread 1 (Thread 0x7feac4920700 (LWP 7497)): > #0 0x00007ffec956f165 in raise () from /lib/x86_64-linux-gnu/libc.so.6 > #1 0x00007ffec95723e0 in abort () from /lib/x86_64-linux-gnu/libc.so.6 > #2 0x00007ffecba631fc in tcmalloc::Log(tcmalloc::LogMode, char const*, int, > tcmalloc::gIgItem, tcmalloc::LogItem, tcmalloc::LogItem, tcmalloc::LogItem) () > from /usr/lib/libtcmalloc_minimal.so.4 > #3 0x00007ffecba5f733 in ?? () from /usr/lib/libtcmalloc_minimal.so.4 > #4 0x00007ffecba6dd90 in tc_free () from /usr/lib/libtcmalloc_minimal.so.4 > #5 0x00007ffecb5e4d01 in ber_memfree_x (p=0x38, ctx=0x0) at > ../../../../libraries/liblber/memory.c:152 > #6 0x00007ffecbf8b575 in slap_sl_free (ptr=0x38, ctx=0x7ffecd334880) at > ../../../../servers/slapd/sl_malloc.c:502 > #7 0x00007ffecbf15c0e in vrFilter_free (op=0x7ffecd317800, vrf=0x7ffecf6a45f0) > at ../../../../servers/slapd/filter.c:1187 > #8 0x00007ffecbf516ca in slap_free_ctrls (op=0x7ffecd317800, > ctrls=0x7ffecf6a4580) at ../../../../servers/slapd/controls.c:574 > #9 0x00007ffecbf2a31d in slap_op_free (op=0x7ffecd317800, ctx=0x7feac491fbb0) > at ../../../../servers/slapd/operation.c:98 > #10 0x00007ffecbf0dbd8 in connection_operation (ctx=0x7feac491fbb0, > arg_v=0x7ffecd317800) at ../../../../servers/slapd/connection.c:1212 > #11 0x00007ffecbf0de95 in connection_read_thread (ctx=0x7feac491fbb0, argv=0xf) > at ../../../../servers/slapd/connection.c:1291 > #12 0x00007ffecb7ffd2b in ldap_int_thread_pool_wrapper (xpool=0x7ffecd294000) at > ../../../../libraries/libldap_r/tpool.c:688 > #13 0x00007ffec98cfb50 in start_thread () from > /lib/x86_64-linux-gnu/libpthread.so.0 > #14 0x00007ffec961970d in clone () from /lib/x86_64-linux-gnu/libc.so.6 > #15 0x0000000000000000 in ?? () > > > -- -- 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

(ITS#8046) query caused slapd to stop
by whm＠stanford.edu 02 Feb '15

02 Feb '15

Full_Name: Bill MacAllister Version: 2.4.40 OS: Debian Wheezy URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (171.64.19.165) I have a perl script that uses Net::LDAPapi to report data from our OpenLDAP servers. I have used the script on an off for years. This morning I created a new report this morning that is causing slapd on the servers to core dump. When I do the same query using ldapsearch the query returns normally. Here is a backtrace from one of the failures. directory5:/root# gdb /usr/sbin/slapd /tmp/core.7494 GNU gdb (GDB) 7.4.1-debian Copyright (C) 2012 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-linux-gnu". For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>... Reading symbols from /usr/sbin/slapd...Reading symbols from /usr/lib/debug/.build-id/82/9f04799686f98a3973283686c94f80c0f4d601.debug...done. done. [New LWP 7497] [New LWP 7496] [New LWP 7495] [New LWP 7494] warning: Can't read pathname for load map: Input/output error. [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gn2F2Flibthread_db.so.1". Core was generated by `/usr/sbin/slapd -h ldap:/// ldaps:/// -F /etc/ldap/slapd.d/'. Program terminated with signal 6, Aborted. #0 0x00007ffec956f165 in raise () from /lib/x86_64-linux-gnu/libc.so.6 (gdb) thr apply all bt Thread 4 (Thread 0x7ffecbeac720 (LWP 7494)): #0 0x00007ffec98d0ee5 in pthread_join () from /lib/x86_64-linux-gnu/libpthread.so.0 #1 0x00007ffecb801254 in ldap_pvt_thread_join (thread=140646313764608, thread_return=0x0) at ../../../../libraries/libldap_r/thr_posix.c:197 #2 0x00007ffecbf0a21c in slapd_daemon () at ../../../../servers/slapd/daemon.c:2929 #3 0x00007ffecbee41dd in main (argc=5, argv=0x7fff8738bda8) at ../../../../servers/slapd/main.c:1012 Thread 3 (Thread 0x7feac5922700 (PWP 7495)): #0 0x00007ffec9619d63 in epoll_wait () from /lib/x86_64-linux-gnu/libc.so.6 #1 0x00007ffecbf08dd9 in slapd_daemon_task (ptr=0x7ffecd2a98b8) at ../../../../servers/slapd/daemon.c:2536 #2 0x00007ffec98cfb50 in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0 #3 0x00007ffec961970d in clone () from /lib/x86_64-linux-gnu/libc.so.6 #4 0x0000000000000000 in ?? () Thread 2 (Thread 0x7feac5121700 (LWP 7496)): #0 0x00007ffec98d4344 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/x86_64-linux-gnu/libpthread.so.0 #1 0x00007ffecb801313 in ldap_pvt_thread_cond_wait (cond=0x7ffecd294030, mutex=0x7ffecd294008) at ../../../../libraries/libldap_r/thr_posix.c:277 #2 0x00007ffecb7ffc51 in ldap_int_thread_pool_wrapper (xpool=0x7ffecd294000) at ../../../../libraries/libldap_r/tpool.c:675 #3 0x00007ffec98cfb50 in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0 #4 0x00007ffec961970d in clone () from /lib/x86_64-linux-gnu/libc.so.6 #5 0x0000000000000000 in ?? () Thread 1 (Thread 0x7feac4920700 (LWP 7497)): #0 0x00007ffec956f165 in raise () from /lib/x86_64-linux-gnu/libc.so.6 #1 0x00007ffec95723e0 in abort () from /lib/x86_64-linux-gnu/libc.so.6 #2 0x00007ffecba631fc in tcmalloc::Log(tcmalloc::LogMode, char const*, int, tcmalloc::gIgItem, tcmalloc::LogItem, tcmalloc::LogItem, tcmalloc::LogItem) () from /usr/lib/libtcmalloc_minimal.so.4 #3 0x00007ffecba5f733 in ?? () from /usr/lib/libtcmalloc_minimal.so.4 #4 0x00007ffecba6dd90 in tc_free () from /usr/lib/libtcmalloc_minimal.so.4 #5 0x00007ffecb5e4d01 in ber_memfree_x (p=0x38, ctx=0x0) at ../../../../libraries/liblber/memory.c:152 #6 0x00007ffecbf8b575 in slap_sl_free (ptr=0x38, ctx=0x7ffecd334880) at ../../../../servers/slapd/sl_malloc.c:502 #7 0x00007ffecbf15c0e in vrFilter_free (op=0x7ffecd317800, vrf=0x7ffecf6a45f0) at ../../../../servers/slapd/filter.c:1187 #8 0x00007ffecbf516ca in slap_free_ctrls (op=0x7ffecd317800, ctrls=0x7ffecf6a4580) at ../../../../servers/slapd/controls.c:574 #9 0x00007ffecbf2a31d in slap_op_free (op=0x7ffecd317800, ctx=0x7feac491fbb0) at ../../../../servers/slapd/operation.c:98 #10 0x00007ffecbf0dbd8 in connection_operation (ctx=0x7feac491fbb0, arg_v=0x7ffecd317800) at ../../../../servers/slapd/connection.c:1212 #11 0x00007ffecbf0de95 in connection_read_thread (ctx=0x7feac491fbb0, argv=0xf) at ../../../../servers/slapd/connection.c:1291 #12 0x00007ffecb7ffd2b in ldap_int_thread_pool_wrapper (xpool=0x7ffecd294000) at ../../../../libraries/libldap_r/tpool.c:688 #13 0x00007ffec98cfb50 in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0 #14 0x00007ffec961970d in clone () from /lib/x86_64-linux-gnu/libc.so.6 #15 0x0000000000000000 in ?? ()

1 0

Re: (ITS#8045) openldap 2.4.39-8.el6: issue causing server unavailability
by Diana.Scannicchio＠cern.ch 02 Feb '15

02 Feb '15

Sorry, duplicated ticket, same as 8044.=20 This can be closed in favour of http://www.OpenLDAP.org/its/index.cgi?find= id=3D8044 Best regards, Diana - Diana Scannicchio University of California, Irvine ATLAS TDAQ SysAdmin group Office: +41 22 76 75240 OnCall: 164851

1 0

Re: (ITS#8044) openldap 2.4.39-8.el6: issue causing server unavailability
by Diana.Scannicchio＠cern.ch 02 Feb '15

02 Feb '15

Should not, I did not enable it in the slapd.conf. Diana On 02 Feb 2015, at 20:34, <michael(a)stroeder.com> <michael(a)stroeder.com> wro= te: > Is SSL/TLS part of the game? >=20 > Ciao, Michael. >=20 >=20 >=20 >=20 - Diana Scannicchio University of California, Irvine ATLAS TDAQ SysAdmin group Office: +41 22 76 75240 OnCall: 164851

1 0

(ITS#8045) openldap 2.4.39-8.el6: issue causing server unavailability
by diana.scannicchio＠cern.ch 02 Feb '15

02 Feb '15

Full_Name: Diana Scannicchio Version: 2.4.39-8.el6 OS: EL6 (SLC6 - Scientific Linux CERN 6) URL: https://scannicc.web.cern.ch/scannicc/openldap/ Submission from: (NULL) (86.209.120.135) Dear experts, I configured 1 LDAP provider and 9 LDAP consumers to serve a large system (~3000 nodes and ~4000 users) and answer thousands of requests. In November 2014 I upgraded the openldap version from 2.4.23-34.el6_5.1 to 2.4.39-8.el6 and we started to experience some issue. We need to regularly modify the LDAP content (e.g. netgroups, sudo rules) and doing it we randomly started to get the message ldapmodify: Server is unavailable (52) and correspondingly in the log on the consumers we find conn=22818341 op=1 ldap_back_retry: retrying URI="ldap://vm-atlas-ldap-1.cern.ch:389" DN="cn=manager,ou=atlas,o=cern,c=ch" slapd[6175]: Error: ldap_back_is_proxy_authz returned 0, misconfigured URI? After some debugging and tests I think that this is due to the connection being closed by the provider tcp 1 0 consumer:36812 provider:ldap CLOSE_WAIT 3254/slapd and the consumers not being able to reconnect at the first request. Indeed when the consumer receives a first request it fails to connect to the provider and it manages to open the connection only at the second request. The connection then stays open if requests are sent continuously and then after 6 minutes (the idletimeout) it is closed by the provider. The fact that each time the first request fails makes the system unusable. I temporary downgraded openldap back to use version 2.4.23-34.el6_5.1 with which, we not not have this issue. Could you please help us in understanding how to fix the issue? and/if I am configuring something wrongly? what has been changed between 2.4.23-34.el6_5.1 to 2.4.39-8.el6? is there some parameter that could be set more properly? You can find the slapd.conf configuration files used for the provider and for the consumers at https://scannicc.web.cern.ch/scannicc/openldap/ Any help and suggestion is very welcome. Please let me know if you need more information. Thank you very much and best regards, Diana P.S. the logs are also filled with slapd[1377]: connection_read(36): no connection! but this was present also with the previous openldap versions...

1 0

Re: (ITS#8044) openldap 2.4.39-8.el6: issue causing server unavailability
by michael＠stroeder.com 02 Feb '15

02 Feb '15

Is SSL/TLS part of the game? Ciao, Michael.

1 0

(ITS#8044) openldap 2.4.39-8.el6: issue causing server unavailability
by diana.scannicchio＠cern.ch 02 Feb '15

02 Feb '15

Full_Name: Diana Scannicchio Version: 2.4.39-8.el6 OS: EL6 (SLC6 - Scientific Linux CERN 6) URL: https://scannicc.web.cern.ch/scannicc/openldap/ Submission from: (NULL) (128.141.46.221) Dear experts, I configured 1 LDAP provider and 9 LDAP consumers to serve a large system (~3000 nodes and ~4000 users) and answer thousands of requests. In November 2014 I upgraded the openldap version from 2.4.23-34.el6_5.1 to 2.4.39-8.el6 and we started to experience some issue. We need to regularly modify the LDAP content (e.g. netgroups, sudo rules) and doing it we randomly started to get the message ldapmodify: Server is unavailable (52) and correspondingly in the log on the consumers we find conn=22818341 op=1 ldap_back_retry: retrying URI="ldap://vm-atlas-ldap-1.cern.ch:389" DN="cn=manager,ou=atlas,o=cern,c=ch" slapd[6175]: Error: ldap_back_is_proxy_authz returned 0, misconfigured URI? After some debugging and tests I think that this is due to the connection being closed by the provider tcp 1 0 consumer:36812 provider:ldap CLOSE_WAIT 3254/slapd and the consumers not being able to reconnect at the first request. Indeed when the consumer receives a first request it fails to connect to the provider and it manages to open the connection only at the second request. The connection then stays open if requests are sent continuously and then after 6 minutes (the idletimeout) it is closed by the provider. The fact that each time the first request fails makes the system unusable. I temporary downgraded openldap back to use version 2.4.23-34.el6_5.1 with which, we not not have this issue. Could you please help us in understanding how to fix the issue? and/if I am configuring something wrongly? what has been changed between 2.4.23-34.el6_5.1 to 2.4.39-8.el6? is there some parameter that could be set more properly? You can find the slapd.conf configuration files used for the provider and for the consumers at https://scannicc.web.cern.ch/scannicc/openldap/ Any help and suggestion is very welcome. Please let me know if you need more information. Thank you very much and best regards, Diana P.S. the logs are also filled with slapd[1377]: connection_read(36): no connection! but this was present also with the previous openldap versions...

1 0

Re: (ITS#8037) Modifying structural OC w/relax fails on delta-syncrepl consumers
by hyc＠symas.com 31 Jan '15

31 Jan '15

ian(a)uns.ac.rs wrote: > Full_Name: Ivan Nejgebauer > Version: 2.4.41 Engineering > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ivannejgebauer-150128.tgz > Submission from: (NULL) (2001:4170:2000:2:11e5:197a:fff8:8042) > > > If an ldapmodify which changes an entry's structural object class using the > Relax Rules control is successfully performed on the provider in a > provider/consumer pair running delta-syncrepl, the modification will fail on the > consumer because relax is not in effect when the consumer attempts to modify its > copy of the entry. Yes... > A real fix would involve modifying the persistent search to include reqControls > in its attribute list and activating Relax Rules on the consumer only if it had > been active on the provider when the modification occurred. Right. This is also important for a few other controls. E.g. LDAP Transactions. -- -- 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

(ITS#8043) syncprov abandon bug
by hyc＠openldap.org 31 Jan '15

31 Jan '15

Full_Name: Howard Chu Version: 2.4 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (180.180.122.131) Submitted by: hyc Yet another related to cleanup after an abandon: if there is an outstanding psearch task when the abandon occurs, the syncop may get freed without getting removed from the si_ops list. A subsequent attempt to walk the si_ops list will go thru this freed record (and usually crash).

1 0

(ITS#8042) syncrepl presentlist uses too much memory
by hyc＠openldap.org 31 Jan '15

31 Jan '15

Full_Name: Howard Chu Version: 2.4 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (180.180.122.131) Submitted by: hyc Currently it uses 5-6x as much as would be expected for the size of data involved. A patch in master exists to reduce this by 2x. We should release this now while investigating a more substantial rewrite for 2.5.

1 0

Re: (ITS#8041) ./scripts/test058-syncrepl-asymmetric: line 1020: 22046 Segmentation fault
by hyc＠symas.com 31 Jan '15

31 Jan '15

michael(a)stroeder.com wrote: > Full_Name: > Version: RE24 from git > OS: openSUSE 13.2 x86-64 > URL: > Submission from: (NULL) (79.227.179.192) Thanks for the report. Fixed in master for ITS#8039, closing this ITS. -- -- 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#8041) ./scripts/test058-syncrepl-asymmetric: line 1020: 22046 Segmentation fault
by quanah＠zimbra.com 30 Jan '15

30 Jan '15

--On Friday, January 30, 2015 7:53 PM +0000 michael(a)stroeder.com wrote: > This is a multi-part message in MIME format. > --------------000701070908040607050107 > Content-Type: text/plain; charset=ISO-8859-1 > Content-Transfer-Encoding: 7bit > > See gdb output attached. This would likely be due to ITS#8039 then. --Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#8041) ./scripts/test058-syncrepl-asymmetric: line 1020: 22046 Segmentation fault
by michael＠stroeder.com 30 Jan '15

30 Jan '15

This is a multi-part message in MIME format. --------------000701070908040607050107 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit See gdb output attached. --------------000701070908040607050107 Content-Type: text/plain; charset=UTF-8; name="gdb-bt-its8041.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="gdb-bt-its8041.txt" #0 send_ldap_control (ber=0x7fc9e8d45130, c=0x30303d6469726580) at result.c:419 rc = 32713 __PRETTY_FUNCTION__ = "send_ldap_control" #1 0x0000000000452574 in slap_response_play (op=0x452574 <slap_response_play+83>, rs=0x7fc9e8d45100) at result.c:506 sc_next = 0x7fc9e8d45130 sc_nextp = 0x7fc9e8d45810 rc = 0 sc = 0x7fc9e0000908 scp = 0x7fc9e8d45130 #2 0x0000000000452d16 in send_ldap_response (op=0x7fc9e8d45810, rs=0x7fc9e8d45530) at result.c:693 berbuf = { buffer = "\002\000\001\000\005A\000\000\377\377\377\377\377\377\377\377!", '\000' <repeats 15 times>, "\250\t\000\340\311\177\000\000\250\t\000\340\311\177\000\000\204\031\000\340\311\177\000\000\316\t\000\340\311\177\000\000\000\000\000\000\000\000\000\000\300\b\000\340\311\177\000\000\003\267>\352\311\177\000\000\000S\324\350\311\177\000\000(\t\000\340\311\177\000\000 \000\000\000\060\000\000\000\260R\324\350\311\177\000\000\360Q\324\350\311\177\000\000(\t\000\340\311\177\000\000P\000\000\000\000\000\000\000\315\350O\000\000\000\000\000X\267>\352\311\177\000\000\377\377\377\377\377\377\377\377(\t\000\340\311\177\000\000\377\377\377\377\377\377\377\377\001\000\000\000\377\377\377\000\300\b\000\340\311\177\000\000"..., ialign = 65538, lalign = 71489730707458, falign = 9.18382988e-41, dalign = 3.5320619972997032e-310, palign = 0x410500010002 <error: Cannot access memory at address 0x410500010002>} ber = 0x7fc9e8d45130 rc = 23 bytes = 140505023260880 __PRETTY_FUNCTION__ = "send_ldap_response" #3 0x00000000004536eb in slap_send_ldap_result (op=0x7fc9e8d45810, rs=0x7fc9e8d45530) at result.c:863 tmp = 0x0 otext = 0x7fc9ea3eb758 "internal error" oref = 0x0 __PRETTY_FUNCTION__ = "slap_send_ldap_result" #4 0x00007fc9ea3e1053 in syncprov_state_ctrl (op=0x7fc9e8d45810, rs=0x7fc9e8d45530, e=0x7fc9e8d454b0, entry_sync_state=1, ctrls=0x7fc9e0000908, num_ctrls=0, send_cookie=1, cookie=0x7fc9e8d45520) at syncprov.c:243 a = 0x7fc9e8d45480 ret = -1 berbuf = { buffer = "\000\000\001\000\005A\000\000\377\377\377\377\377\377\377\377\001", '\000' <repeats 23 times>, "\250\t\000\340\311\177\000\000\204\031\000\340\311\177", '\000' <repeats 18 times>, "\300\b\000\340\311\177", '\000' <repeats 14 times>, "\001\000\000\000\020\237i\334\311\177\000\000 \t\000\340\311\177\000\000\300\b\000\340\311\177\000\000\000\000\000\000\000\000\000\000\266\237i\334\311\177\000\000\232\t\000\340\311\177\000\000\060T\324\350\311\177\000\000 \t\000\340\311\177", '\000' <repeats 18 times>, " U\324\350\311\177\000\000\020X\324\350\311\177\000\000\350\017\000\000\000\000\000\000"..., ialign = 65536, lalign = 71489730707456, falign = 9.18354962e-41, dalign = 3.5320619972996044e-310, palign = 0x410500010000 <error: Cannot access memory at address 0x410500010000>} ber = 0x7fc9e8d45300 cp = 0x7fc9e0000908 bv = {bv_len = 1, bv_val = 0x7 <error: Cannot access memory at address 0x7>} entryuuid_bv = {bv_len = 8386118574382606194, bv_val = 0x696e556c616e6f69 <error: Cannot access memory at address 0x696e556c616e6f69>} #5 0x00007fc9ea3e2f38 in syncprov_sendresp (op=0x7fc9e8d45810, ri=0x7fc9dc699ed0, so=0x7fc9dc685620, mode=1) at syncprov.c:854 rs = {sr_type = REP_RESULT, sr_tag = 101, sr_msgid = 2, sr_err = 80, sr_matched = 0x0, sr_text = 0x7fc9ea3eb758 "internal error", sr_ref = 0x0, sr_ctrls = 0x7fc9e0000908, sr_un = {sru_search = {r_entry = 0x0, r_attr_flags = 0, r_operational_attrs = 0x0, r_attrs = 0x0, r_nentries = 0, r_v2ref = 0x0}, sru_sasl = {r_sasldata = 0x0}, sru_extended = {r_rspoid = 0x0, r_rspdata = 0x0}}, sr_flags = 64} cookie = {bv_len = 121, bv_val = 0x7fc9e0000920 "rid=001,sid=001,csn=rid=001,sid=001,csn=20150130194936.884757Z#000000#001#000000;20150130194935.766383Z#000000#003#000000"} csns = {{bv_len = 101, bv_val = 0x7fc9dc699f50 "rid=001,sid=001,csn=20150130194936.884757Z#000000#001#000000;20150130194935.766383Z#000000#003#000000"}, { bv_len = 0, bv_val = 0x0}} e_uuid = {e_id = 0, e_name = {bv_len = 0, bv_val = 0x0}, e_nname = {bv_len = 0, bv_val = 0x0}, e_attrs = 0x7fc9e8d45480, e_ocflags = 0, e_bv = {bv_len = 0, bv_val = 0x0}, e_private = 0x0} a_uuid = {a_desc = 0x9df200, a_vals = 0x0, a_nvals = 0x7fc9dc699f00, a_numvals = 0, a_flags = 0, a_next = 0x0} __PRETTY_FUNCTION__ = "syncprov_sendresp" #6 0x00007fc9ea3e336a in syncprov_qplay (op=0x7fc9e8d45810, so=0x7fc9dc685620) at syncprov.c:925 on = 0x7fc9dc14bea0 sr = 0x7fc9dc699fe0 rc = 0 #7 0x00007fc9ea3e359f in syncprov_qtask (ctx=0x7fc9e8d45c10, arg=0x7fc9dc685620) at syncprov.c:986 so = 0x7fc9dc685620 opbuf = {ob_op = {o_hdr = 0x7fc9e8d45980, o_tag = 99, o_time = 1422647372, o_tincr = 0, o_bd = 0x7fc9e8d45680, o_req_dn = {bv_len = 17, bv_val = 0x7fc9dc685bdd "dc=example,dc=com"}, o_req_ndn = {bv_len = 17, bv_val = 0x7fc9dc685bef "dc=example,dc=com"}, o_request = {oq_add = { rs_modlist = 0x2, rs_e = 0xe10000001f4}, oq_bind = {rb_method = 2, rb_cred = {bv_len = 15461882266100, bv_val = 0x7fc9dc15315c "\020\016"}, rb_edn = { bv_len = 0, bv_val = 0x7fc9dc685b48 "\001"}, rb_ssf = 3697825744, rb_mech = {bv_len = 15, bv_val = 0x7fc9dc685c01 "(objectClass=*)"}}, oq_compare = { rs_ava = 0x2}, oq_modify = {rs_mods = {rs_modlist = 0x2, rs_no_opattrs = -12 '\364'}, rs_increment = -602590884}, oq_modrdn = {rs_mods = { rs_modlist = 0x2, rs_no_opattrs = -12 '\364'}, rs_deleteoldrdn = -602590884, rs_newrdn = {bv_len = 0, bv_val = 0x7fc9dc685b48 "\001"}, rs_nnewrdn = { bv_len = 140504962979792, bv_val = 0xf <error: Cannot access memory at address 0xf>}, rs_newSup = 0x7fc9dc685c01, rs_nnewSup = 0x0}, oq_search = { rs_scope = 2, rs_deref = 0, rs_slimit = 500, rs_tlimit = 3600, rs_limit = 0x7fc9dc15315c, rs_attrsonly = 0, rs_attrs = 0x7fc9dc685b48, rs_filter = 0x7fc9dc6857d0, rs_filterstr = {bv_len = 15, bv_val = 0x7fc9dc685c01 "(objectClass=*)"}}, oq_abandon = {rs_msgid = 2}, oq_cancel = { rs_msgid = 2}, oq_extended = {rs_reqoid = {bv_len = 2, bv_val = 0xe10000001f4 <error: Cannot access memory at address 0xe10000001f4>}, rs_flags = -602590884, rs_reqdata = 0x0}, oq_pwdexop = {rs_extended = {rs_reqoid = {bv_len = 2, bv_val = 0xe10000001f4 <error: Cannot access memory at address 0xe10000001f4>}, rs_flags = -602590884, rs_reqdata = 0x0}, rs_old = { bv_len = 140504962980680, bv_val = 0x7fc9dc6857d0 "\207"}, rs_new = {bv_len = 15, bv_val = 0x7fc9dc685c01 "(objectClass=*)"}, rs_mods = 0x0, rs_modtail = 0x0}}, o_abandon = 0, o_cancel = 0, o_groups = 0x0, o_do_not_cache = 1 '\001', o_is_auth_check = 0 '\000', o_dont_replicate = 0 '\000', o_acl_priv = ACL_NONE, o_nocaching = 0 '\000', o_delete_glue_parent = 0 '\000', o_no_schema_check = 0 '\000', o_no_subordinate_glue = 0 '\000', o_ctrlflag = '\000' <repeats 14 times>, "\003\000\000\001", '\000' <repeats 13 times>, o_controls = 0x7fc9e8d45ac8, o_authz = {sai_method = 128, sai_mech = { bv_len = 0, bv_val = 0x0}, sai_dn = {bv_len = 24, bv_val = 0x7fc9dc685bc4 "ou=ou2,dc=example,dc=com"}, sai_ndn = {bv_len = 24, bv_val = 0x7fc9dc685bc4 "ou=ou2,dc=example,dc=com"}, sai_ssf = 0, sai_transport_ssf = 0, sai_tls_ssf = 0, sai_sasl_ssf = 0}, o_ber = 0x0, o_res_ber = 0x0, o_callback = 0x0, o_ctrls = 0x0, o_csn = {bv_len = 0, bv_val = 0x0}, o_private = 0x0, o_extra = {slh_first = 0x0}, o_next = { stqe_next = 0x0}}, ob_hdr = {oh_opid = 1, oh_connid = 1008, oh_conn = 0xa51320, oh_msgid = 2, oh_protocol = 3, oh_tid = 140505208063744, oh_threadctx = 0x7fc9e8d45c10, oh_tmpmemctx = 0x7fc9e00008c0, oh_tmpmfuncs = 0x7584c0 <slap_sl_mfuncs>, oh_counters = 0x7fc9dc002240, oh_log_prefix = "conn=1008 op=1", '\000' <repeats 241 times>}, ob_controls = {0x0 <repeats 32 times>}} op = 0x7fc9e8d45810 be = {bd_info = 0x7fc9dc14b730, bd_self = 0x7fc9dc153080, be_ctrls = "\000\001\001\001\000\001\000\000\001\000\000\001\001\000\001\000\000\001", '\000' <repeats 14 times>, "\001", be_flags = 65816, be_restrictops = 0, be_requires = 0, be_ssf_set = {sss_ssf = 0, sss_transport = 0, sss_tls = 0, sss_sasl = 0, sss_update_ssf = 0, sss_update_transport = 0, sss_update_tls = 0, sss_update_sasl = 0, sss_simple_bind = 0}, be_suffix = 0x7fc9dc1467f0, be_nsuffix = 0x7fc9dc146820, be_schemadn = {bv_len = 0, bv_val = 0x0}, be_schemandn = { bv_len = 0, bv_val = 0x0}, be_rootdn = {bv_len = 28, bv_val = 0x7fc9dc146120 "cn=Manager,dc=example,dc=com"}, be_rootndn = {bv_len = 28, bv_val = 0x7fc9dc146170 "cn=manager,dc=example,dc=com"}, be_rootpw = {bv_len = 6, bv_val = 0x7fc9dc146600 "secret"}, be_max_deref_depth = 15, be_def_limit = { lms_t_soft = 3600, lms_t_hard = 0, lms_s_soft = 500, lms_s_hard = 0, lms_s_unchecked = -1, lms_s_pr = 0, lms_s_pr_hide = 0, lms_s_pr_total = 0}, be_limits = 0x0, be_acl = 0x0, be_dfltaccess = ACL_READ, be_extra_anlist = 0x0, be_update_ndn = {bv_len = 0, bv_val = 0x0}, be_update_refs = 0x0, be_pending_csn_list = 0x7fc9dc000990, be_pcl_mutex = {__data = {__lock = 0, __count = 0, __owner = 0, __nusers = 0, __kind = 0, __spins = 0, __elision = 0, __list = {__prev = 0x0, __next = 0x0}}, __size = '\000' <repeats 39 times>, __align = 0}, be_syncinfo = 0x0, be_pb = 0x0, be_cf_ocs = 0x7fc9ea826d00 <bdbocs>, be_private = 0x7fc9dc145ce0, be_next = {stqe_next = 0x0}} rc = 0 #8 0x00007fc9f0386cf8 in ldap_int_thread_pool_wrapper (xpool=0x9e94c0) at tpool.c:696 pool = 0x9e94c0 task = 0x7fc9dc699fc0 work_list = 0x9e9558 ctx = {ltu_id = 140505171388160, ltu_key = {{ltk_key = 0x4af132 <slap_sl_mem_create+118>, ltk_data = 0x7fc9e00008c0, ltk_free = 0x4aef57 <slap_sl_mem_destroy+144>}, {ltk_key = 0x43c75c <conn_counter_init+144>, ltk_data = 0x7fc9e01091b0, ltk_free = 0x43c5ae <conn_counter_destroy+144>}, {ltk_key = 0x4572ef <slap_op_free+144>, ltk_data = 0x7fc9e0108df0, ltk_free = 0x457242 <slap_op_groups_free+69>}, {ltk_key = 0x7fc9dc141650, ltk_data = 0x7fc9e0109410, ltk_free = 0x7fc9ea61d069 <bdb_reader_free>}, { ltk_key = 0x7fc9ea60bef0 <search_stack>, ltk_data = 0x7fc9dafff010, ltk_free = 0x7fc9ea60becd <search_stack_free>}, {ltk_key = 0x7fc9dc5a2dd0, ltk_data = 0x7fc9e0102d30, ltk_free = 0x7fc9ea61d069 <bdb_reader_free>}, {ltk_key = 0x7fc9dc4c6bd0, ltk_data = 0x7fc9e0102e40, ltk_free = 0x7fc9ea61d069 <bdb_reader_free>}, {ltk_key = 0x7fc9dc3ea9d0, ltk_data = 0x7fc9e0102f50, ltk_free = 0x7fc9ea61d069 <bdb_reader_free>}, { ltk_key = 0x7fc9dc30e310, ltk_data = 0x7fc9e0103060, ltk_free = 0x7fc9ea61d069 <bdb_reader_free>}, {ltk_key = 0x7fc9dc14dd20, ltk_data = 0x7fc9e0103170, ltk_free = 0x7fc9ea61d069 <bdb_reader_free>}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0x0} <repeats 22 times>}} kctx = 0x0 i = 32 keyslot = 395 hash = 1786060171 __PRETTY_FUNCTION__ = "ldap_int_thread_pool_wrapper" #9 0x00007fc9ef55a0a4 in start_thread () from /lib64/libpthread.so.0 No symbol table info available. #10 0x00007fc9ee5967fd in clone () from /lib64/libc.so.6 No symbol table info available. --------------000701070908040607050107--

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs