openldap-bugs

openldap-bugs@openldap.org

1 participants
21065 discussions

Re: (ITS#7616) syncrepl enhancement: defer requests when refreshing
by hyc＠symas.com 24 Mar '14

24 Mar '14

This is a multi-part message in MIME format. --------------050807020608030505070800 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit hyc(a)symas.com wrote: > Michael Ströder wrote: >> hyc(a)symas.com wrote: >>> I was considering returning LDAP_BUSY for this case, but it may make more >>> sense to return a REFERRAL to the provider instead. (Although again, if we >>> have two MMR servers pointed at each other starting at the same time, they >>> would just refer to each other and clients would get nowhere until one of them >>> finishes its refresh.) >> >> IMO referrals are harmful. >> Just returning LDAP_BUSY seems best to me because if reliable HA is really >> important for a deployment you have decent load-balancers in front of your >> LDAP server which should do a proper health-check. The attached patch should provide the desired behavior. It needs more testing though. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ --------------050807020608030505070800 Content-Type: text/plain; charset=UTF-8; name="diff.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="diff.txt" diff --git a/servers/slapd/syncrepl.c b/servers/slapd/syncrepl.c index 9b5c0f3..4ea8a70 100644 --- a/servers/slapd/syncrepl.c +++ b/servers/slapd/syncrepl.c @@ -148,6 +148,8 @@ static int syncrepl_add_glue_ancestors( /* delta-mmr overlay handler */ static int syncrepl_op_modify( Operation *op, SlapReply *rs ); +static int syncrepl_op_search( Operation *op, SlapReply *rs ); + /* callback functions */ static int dn_callback( Operation *, SlapReply * ); static int nonpresent_callback( Operation *, SlapReply * ); @@ -216,16 +218,14 @@ init_syncrepl(syncinfo_t *si) if ( !syncrepl_ov.on_bi.bi_type ) { syncrepl_ov.on_bi.bi_type = "syncrepl"; syncrepl_ov.on_bi.bi_op_modify = syncrepl_op_modify; + syncrepl_ov.on_bi.bi_op_search = syncrepl_op_search; overlay_register( &syncrepl_ov ); } - /* delta-MMR needs the overlay, nothing else does. - * This must happen before accesslog overlay is configured. - */ - if ( si->si_syncdata && - !overlay_is_inst( si->si_be, syncrepl_ov.on_bi.bi_type )) { + if (!overlay_is_inst( si->si_be, syncrepl_ov.on_bi.bi_type )) { overlay_config( si->si_be, syncrepl_ov.on_bi.bi_type, -1, NULL, NULL ); - if ( !ad_reqMod ) { + /* delta-MMR needs this. Must happen before accesslog overlay is configured. */ + if ( si->si_syncdata && !ad_reqMod ) { const char *text; logschema *ls = &accesslog_sc; @@ -1179,6 +1179,7 @@ do_syncrep2( } else { rc = -2; } + si->si_refreshDone = 1; goto done; case LDAP_RES_INTERMEDIATE: @@ -2164,6 +2165,31 @@ syncrepl_op_modify( Operation *op, SlapReply *rs ) } static int +syncrepl_op_search( Operation *op, SlapReply *rs ) +{ + slap_overinst *on = (slap_overinst *)op->o_bd->bd_info; + syncinfo_t *si; + + /* Allow syncrepl internal searches */ + if ( op->o_conn->c_conn_idx == -1 ) + return SLAP_CB_CONTINUE; + + /* Check if any of our consumers are refreshing */ + for ( si = op->o_bd->be_syncinfo; si; si = si->si_next ) { + /* If we have some state, allow other consumers to progress */ + if ( si->si_cookieState->cs_num > 0 && + op->o_sync > SLAP_CONTROL_IGNORED ) + return SLAP_CB_CONTINUE; + /* If we have any consumer refreshing, reject searches */ + if ( !si->si_refreshDone ) { + send_ldap_error( op, rs, LDAP_BUSY, "syncrepl refresh in progress" ); + return rs->sr_err; + } + } + return SLAP_CB_CONTINUE; +} + +static int syncrepl_message_to_op( syncinfo_t *si, Operation *op, --------------050807020608030505070800--

1 0

Re: (ITS#7336) Ldapmodify crashes slapd when updating olcTLSVerifyClient attribute via TLS authentication
by ck＠cksoft.de 23 Mar '14

23 Mar '14

Hi, I can confirm that openldap-2.4.39 still has in issue with this. When connecting via TLS I tried to modify olcTLSVerifyClient from never to try with following ldif: dn: cn=config changetype: modify replace: olcTLSVerifyClient olcTLSVerifyClient: try this caused slapd to hang indefinetely. I was able to successfully modify above when connecting without TLS. I need to complete my current task but will set up a small proof of concept later on in my lab. Greetings Christian -- Christian Kratzer CK Software GmbH Email: ck(a)cksoft.de Wildberger Weg 24/2 Phone: +49 7032 893 997 - 0 D-71126 Gaeufelden Fax: +49 7032 893 997 - 9 HRB 245288, Amtsgericht Stuttgart Mobile: +49 171 1947 843 Geschaeftsfuehrer: Christian Kratzer Web: http://www.cksoft.de/

1 0

(ITS#7825) LMDB: misleading error message
by timur.kristof＠gmail.com 22 Mar '14

22 Mar '14

Full_Name: Timur Kristóf Version: LMDB latest master OS: Fedora 20 URL: Submission from: (NULL) (94.248.245.60) Hi, I'm the author of the Node.js LMDB binding and I've found an interesting issue that might be useful to share with other people who develop bindings or applications on LMDB. When you operate on a dbi using a cursor and accidentally close the dbi before committing the transaction of the cursor, mdb_txn_commit will return MDB_BAD_VALSIZE. This is quite misleading because the problem doesn't actually have anything to do with what the error message suggests. ("Too big key/data, key is empty, or wrong DUPFIXED size") I suggest to either add a new kind of error code for this situation or to extend the description of MDB_BAD_VALSIZE. Here's a small test case which will demonstrate it: http://pastebin.com/hHwD1srf Best regards, Timur Kristóf

1 0

Re: (ITS#7822) Segmentation fault while modifying olcDbMaxSize
by quanah＠zimbra.com 21 Mar '14

21 Mar '14

--On Friday, March 21, 2014 10:28 AM +0000 frederic.poisson(a)admin.gmessaging.net wrote: > Full_Name: Frederic POISSON > Version: 2.4.39 > OS: Linux RHEL5 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (57.250.229.136) > > > Hello, > I have a Segmentation fault while i'm updating the value of olcDbMaxSize > parameter to a number inside olcDatabase={1}mdb,cn=config. The result of > a gdb backtrace show this error : > > Program received signal SIGSEGV, Segmentation fault. > [Switching to Thread 0x42499940 (LWP 31424)] > 0x0000000000553683 in ppolicy_connection_destroy (bd=0x424989d0, > conn=0x18ab2a50) at ppolicy.c:1260 > 1260 if ( !BER_BVISEMPTY( &pwcons[conn->c_conn_idx].dn )) { > > The ldif for the modification is : > dn: olcDatabase={1}mdb,cn=config > changetype: modify > replace: olcDbMaxSize > olcDbMaxSize: 20737418240 > > I will push onto FTP the full log of the backtrace, the cn=config.ldif > from slapcat. Hoping it could help for resolution. Please provide the full backtrace in the ITS --Quanah -- Quanah Gibson-Mount Architect - Server Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#7824) Segmentation fault while modifying olcDbMaxSize
by frederic.poisson＠admin.gmessaging.net 21 Mar '14

21 Mar '14

Full_Name: Frederic POISSON Version: 2.4.39 OS: Linux RHEL5 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (57.250.229.136) Hello, I have a Segmentation fault while i'm updating the value of olcDbMaxSize parameter to a number inside olcDatabase={1}mdb,cn=config. The result of a gdb backtrace show this error : Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x42499940 (LWP 31424)] 0x0000000000553683 in ppolicy_connection_destroy (bd=0x424989d0, conn=0x18ab2a50) at ppolicy.c:1260 1260 if ( !BER_BVISEMPTY( &pwcons[conn->c_conn_idx].dn )) { The ldif for the modification is : dn: olcDatabase={1}mdb,cn=config changetype: modify replace: olcDbMaxSize olcDbMaxSize: 20737418240 I will push onto FTP the full log of the backtrace, the cn=config.ldif from slapcat. Hoping it could help for resolution. Regards,

1 0

(ITS#7823) Segmentation fault while modifying olcDbMaxSize
by frederic.poisson＠admin.gmessaging.net 21 Mar '14

21 Mar '14

1 0

(ITS#7822) Segmentation fault while modifying olcDbMaxSize
by frederic.poisson＠admin.gmessaging.net 21 Mar '14

21 Mar '14

1 0

(ITS#7821) address of strcasecmp in ldapsearch.c
by heiko.nardmann＠itechnical.de 20 Mar '14

20 Mar '14

Full_Name: Heiko Nardmann Version: 2.4.39 OS: MinGW32 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (2001:a60:f08d:1:159e:f75f:8f0:44f1) In clients/tools/ldapsearch.c the address of 'strcasecmp' is taken (inside 'dosearch()') around line 1455. That means that 'strcasecmp' is exported as an undefined symbol into ldapsearch.o even if 'strcasecmp' is declared as 'always_inline'. MinGW is such a platform which offers 'strcasecmp' by providing an inline version of 'strcasecmp' (redirecting it to 'stricmp'). So this taking of an address breaks linking. Workaround: before 'dosearch()' I place a local wrapper: static int local_strcasecmp(const char *s1, const char *s2) { return strcasecmp(s1, s2); } and inside 'dosearch' instead of if( sortattr ) { (void) ldap_sort_entries( ld, &res, ( *sortattr == '\0' ) ? NULL : sortattr, strcasecmp ); } I now have if( sortattr ) { (void) ldap_sort_entries( ld, &res, ( *sortattr == '\0' ) ? NULL : sortattr, local_strcasecmp ); } Some options to really solve that issue: 1) use my approach for all platforms. 2) change autoconf stuff to detect whether 'strcasecmp' is just inlined (MinGW) or a "real" function (other platforms). Thx in advance! Heiko

1 0

Re: (ITS#7587) slapd crashes when using pcache overlay applied to a translucent proxy
by hyc＠symas.com 18 Mar '14

18 Mar '14

amoneger(a)cisco.com wrote: > Full_Name: Alex > Version: 2.4.35 > OS: Centos 6.3 (2.6.32-279.el6.x86_64 #1 SMP) > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (64.103.25.102) > > > When using the pcache overlay over a translucent proxy, the slapd daemon crashes > after the second LDAP request which misses the cache. For example, the following > requests will trigger the issue. The important part is to miss the cache. > Assuming nothing is cached for the aaaa and bbbb uid, the following request will > trigger the issue (172.16.206.156 being the openldap server): Thanks for the report, this is now fixed in git master. > ldapsearch -x -H ldap://172.16.206.156 -b "ou=yyyy,o=xxxx" -LLL "uid=aaaa" uid > st > ldapsearch -x -H ldap://172.16.206.156 -b "ou=yyyy,o=xxxx" -LLL "uid=bbbb" uid > st > > Whether aaaa and bbbb exist or not does not matter. > > The following config is used: > > include /usr/local/etc/openldap/schema/core.schema > include /usr/local/etc/openldap/schema/cosine.schema > include /usr/local/etc/openldap/schema/inetorgperson.schema > include /usr/local/etc/openldap/schema/misc.schema > include /usr/local/etc/openldap/schema/nis.schema > > moduleload pcache.la > moduleload translucent.la > > database bdb > suffix "o=xxxx" > #checkpoint 1024 15 > rootdn "uid=amoneger,ou=yyyy,o=xxxx" > overlay translucent > translucent_local uidNumber,gidNumber,homeDirectory,loginShell > translucent_strict > rootdn "uid=amoneger,ou=yyyy,o=xxxx" > uri ldap://zzzz/ > #tls ldaps tls_reqcert=demand > tls_cacert=/usr/local/etc/openldap/certs/Cisco_ca_chain > overlay pcache > pcache bdb 10000 1 50 100 > pcacheAttrset 0 * > pcacheTemplate (uid=) 0 3600 > pcacheBind (uid=) 0 1800 sub ou=yyyy,o=xxxx > pcacheOffline TRUE > pcachePersist TRUE > pcacheValidate FALSE > directory /var/cache/ldap > cachesize 1000 > index pcacheQueryid eq > > The crash seems to be caused by a SIGABRT which is raised by libc free() due to > a double free. Here is the traceback: > Breakpoint 2, 0x000000312aa33f10 in abort () from /lib64/libc.so.6 > (gdb) c > Continuing. > > Program received signal SIGABRT, Aborted. > 0x000000312aa328a5 in raise () from /lib64/libc.so.6 > (gdb) bt > #0 0x000000312aa328a5 in raise () from /lib64/libc.so.6 > #1 0x000000312aa34085 in abort () from /lib64/libc.so.6 > #2 0x000000312aa707b7 in __libc_message () from /lib64/libc.so.6 > #3 0x000000312aa760e6 in malloc_printerr () from /lib64/libc.so.6 > #4 0x000000000042391e in do_search (op=0x7f135c000b80, rs=0x7f1366764930) at > search.c:263 > #5 0x0000000000421449 in connection_operation (ctx=0x7f1366764a90, > arg_v=0x7f135c000b80) at connection.c:1155 > #6 0x0000000000421c25 in connection_read_thread (ctx=0x7f1366764a90, > argv=<value optimized out>) at connection.c:1291 > #7 0x00000000005601f0 in ldap_int_thread_pool_wrapper (xpool=0x1f42770) at > tpool.c:688 > #8 0x000000312b207851 in start_thread () from /lib64/libpthread.so.0 > #9 0x000000312aae890d in clone () from /lib64/libc.so.6 > > I was unable to track back the particular piece of code triggering the double > free, but the same pointer p is freed twice by ber_memfree_x() in memory.c: > > (gdb) delete 3 > (gdb) break search.c:263 > Breakpoint 4 at 0x5645df: file search.c, line 263. > (gdb) c > Continuing. > > Breakpoint 4, do_search (op=0x7fa554002930, rs=0x7fa5623a4930) at search.c:263 > 263 op->o_tmpfree( op->ors_attrs, op->o_tmpmemctx ); > (gdb) s > slap_sl_free (ptr=0x1d64a10, ctx=0x7fa554002780) at sl_malloc.c:493 > 493 { > (gdb) s > 498 if (!ptr) > (gdb) s > 501 if (No_sl_malloc || !sh || ptr < sh->sh_base || ptr >= sh->sh_end) { > (gdb) s > 502 ber_memfree_x(ptr, NULL); > (gdb) s > 649 } > (gdb) s > 502 ber_memfree_x(ptr, NULL); > (gdb) s > ber_memfree_x (p=0x1d64a10, ctx=0x0) at memory.c:127 > 127 { > (gdb) s > 128 if( p == NULL ) { > (gdb) s > 134 if( ber_int_memory_fns == NULL || ctx == NULL ) { > (gdb) s > 160 } > (gdb) s > 152 free( p ); > (gdb) print p > $1 = (void *) 0x1d64a10 > (gdb) x/10x p > 0x1d64a10: 0x00000001 0x00000000 0x005ffd31 0x00000000 > 0x1d64a20: 0x00000000 0x00000000 0x00000000 0x00000000 > 0x1d64a30: 0x00000000 0x00000000 > (gdb) c > Continuing. > [New Thread 0x7fa561994700 (LWP 5823)] > > Breakpoint 4, do_search (op=0x7fa554002930, rs=0x7fa5623a4930) at search.c:263 > 263 op->o_tmpfree( op->ors_attrs, op->o_tmpmemctx ); > (gdb) s > slap_sl_free (ptr=0x1d64a10, ctx=0x7fa554002780) at sl_malloc.c:493 > 493 { > (gdb) s > 498 if (!ptr) > (gdb) s > 501 if (No_sl_malloc || !sh || ptr < sh->sh_base || ptr >= sh->sh_end) { > (gdb) s > 502 ber_memfree_x(ptr, NULL); > (gdb) s > 649 } > (gdb) s > 502 ber_memfree_x(ptr, NULL); > (gdb) s > ber_memfree_x (p=0x1d64a10, ctx=0x0) at memory.c:127 > 127 { > (gdb) s > 128 if( p == NULL ) { > (gdb) s > 134 if( ber_int_memory_fns == NULL || ctx == NULL ) { > (gdb) s > 160 } > (gdb) s > 152 free( p ); > (gdb) print P > No symbol "P" in current context. > (gdb) print p > $2 = (void *) 0x1d64a10 > (gdb) x/10x p > 0x1d64a10: 0x00000000 0x00000000 0x005ffd31 0x00000000 > 0x1d64a20: 0x00000000 0x00000000 0x00000000 0x00000000 > 0x1d64a30: 0x00000000 0x00000000 > > So the same pointer is being freed twice by the 2 connections which miss the > cache. I'm unable to figure out who is responsible for that call though, but the > same op->ors_attrs is freed by do_search(): > > if ( op->ors_attrs != NULL ) { > op->o_tmpfree( op->ors_attrs, op->o_tmpmemctx ); > > Parameters seem correct in both cases: > (gdb) print op->o_hdr->oh_tmpmfuncs->bmf_free > $12 = (BER_MEMFREE_FN *) 0x4733f0 <slap_sl_free> > (gdb) print op->o_request.oq_search.rs_attrs > $15 = (AttributeName *) 0x1f85a10 > > The call is done via connection_operation(), but that code part is a bit above > my head, so I'm unable to track this further. > > I thought this could be due to a threading problem, but building slapd with > --with-threads=no does not make a difference. > > I tried uploading the core dump to your ftp server, but seems like there is an > issue with ftp.openldap.org > [root@centos63 tmp]# ftp ftp.openldap.org > Trying 204.152.186.57... > Connected to ftp.openldap.org (204.152.186.57). > 220- OpenLDAP FTP Service > 220 boole.openldap.org FTP server (Version 6.00LS) ready. > Name (ftp.openldap.org:cisco): anonymous > 331 Guest login ok, send your email address as password. > Password: > 230- Copyright 1998-2010, The OpenLDAP Foundation, All Rights Reserved. > 230- COPYING RESTRICTIONS APPLY, see: > 230- ftp://ftp.openldap.org/COPYRIGHT > 230- ftp://ftp.openldap.org/LICENSE > 230 Guest login ok, access restrictions apply. > Remote system type is UNIX. > Using binary mode to transfer files. > ftp> cd incoming > 250 CWD command successful. > ftp> binary > 200 Type set to I. > ftp> put core-slapd-6-55-55-26548-1368063267 > local: core-slapd-6-55-55-26548-1368063267 remote: > core-slapd-6-55-55-26548-1368063267 > 227 Entering Passive Mode (204,152,186,57,242,33) > 553 core-slapd-6-55-55-26548-1368063267: No space left on device. > > Let me know if you need anything. I can provide further debugs or cores. I'm > also happy to try things out. > > Cheers, > Alex > > -- -- 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#7723
by hyc＠symas.com 18 Mar '14

18 Mar '14

michael(a)stroeder.com wrote: > Could anybody please review the patch Jan provided in his last follow-up? > > http://www.openldap.org/its/index.cgi?findid=7723#followup9 > > Anythin wrong with his reference count fix? > > We are getting occasional seg faults in slapo-rwm which are very hard to > reproduce and therefore are considering this patch. Looks OK to me, committed to master. Please report back any positive/negative results. -- -- 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

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs