openldap-bugs

openldap-bugs@openldap.org

1 participants
21001 discussions

Re: (ITS#7739) Include of include badly handled while converting from slapd.conf to slapd.d
by hyc＠symas.com 05 Nov '13

05 Nov '13

Raphaël Ouazana-Sustowski wrote: > Hi, > > Le 04/11/2013 17:06, Howard Chu a écrit : >> raphael.ouazana(a)linagora.com wrote: >>> Full_Name: Raphael Ouazana >>> Version: 2.4.37 >>> OS: Linux >>> URL: ftp://ftp.openldap.org/incoming/ >>> Submission from: (NULL) (88.173.78.196) >>> >>> >>> Hi, >>> >>> If I have for example a main slapd.conf with: >>> include <path>schema.conf >>> >>> And a simple schema.conf: >>> include <path>core.schema >>> include <path>cosine.schema >>> include <path>inetorgperson.schema >>> >>> When I try to convert slapd.conf to slapd.d with slaptest, the >>> resulting >>> configuration is incorrect: the schema file are not included. >>> >> >> Try again, using a different name than "schema.conf" > > It doesn't work neither. > > Steps to reproduce: > > 1. basic slapd.conf, but: > a. replace include <schemapath>core.schema by include > <configpath>morethings.conf > b. add index sn eq at the end > > 2. create <configpath>morethings.conf including only > <schemapath>core.schema Fixed now in master. -- -- 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#7740) back-meta lock threads when remote node is unreachable
by hyc＠symas.com 05 Nov '13

05 Nov '13

jorge.perez.burgos(a)ericsson.com wrote: > Full_Name: Jorge Perez Burgos > Version: 2.4.35 > OS: SLES 11 > URL: ftp://ftp.openldap.org/incoming/0001-Don-t-lock-other-threads-while-trying-… > Submission from: (NULL) (195.235.15.243) > > > When there is meta proxy traffic to another node and this node becomes > unreachable the thread in meta retrying to connect to the remote node locks all > the other threads making the slapd unresponsive until the timeout expires. > Attach a possible fix > ftp://ftp.openldap.org/incoming/0001-Don-t-lock-other-threads-while-trying-… > > and a backtraceo of some threads when the problem happens: Thanks, the patch looks OK, committed to git master. -- -- 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#7740) back-meta lock threads when remote node is unreachable
by jorge.perez.burgos＠ericsson.com 05 Nov '13

05 Nov '13

Full_Name: Jorge Perez Burgos Version: 2.4.35 OS: SLES 11 URL: ftp://ftp.openldap.org/incoming/0001-Don-t-lock-other-threads-while-trying-… Submission from: (NULL) (195.235.15.243) When there is meta proxy traffic to another node and this node becomes unreachable the thread in meta retrying to connect to the remote node locks all the other threads making the slapd unresponsive until the timeout expires. Attach a possible fix ftp://ftp.openldap.org/incoming/0001-Don-t-lock-other-threads-while-trying-… and a backtraceo of some threads when the problem happens: Thread 259 (Thread 0x7ff9a771e700 (LWP 27085)): #0 0x00007ff9fc2a6294 in __lll_lock_wait () from /lib64/libpthread.so.0 #1 0x00007ff9fc2a1619 in _L_lock_1008 () from /lib64/libpthread.so.0 #2 0x00007ff9fc2a142e in pthread_mutex_lock () from /lib64/libpthread.so.0 #3 0x00000000004b6007 in meta_back_search (op=0x31a8800, rs=0x7ff9a771d930) at search.c:2012 #4 0x000000000043ab31 in fe_op_search (op=0x31a8800, rs=0x7ff9a771d930) at search.c:402 #5 0x00000000004a0ef7 in overlay_op_walk (op=0x31a8800, rs=0x7ff9a771d930, which=op_search, oi=0x87cc000, on=0x0) at backover.c:671 #6 0x00000000004a1970 in over_op_func (op=0x31a8800, rs=0x7ff9a771bdc8, which=op_bind) at backover.c:723 #7 0x000000000043b37c in do_search (op=0x31a8800, rs=0x7ff9a771d930) at search.c:247 #8 0x0000000000437eef in connection_operation (ctx=0x7ff9a771db30, arg_v=<optimized out>) at connection.c:1313 #9 0x0000000000438b1b in connection_read_thread (ctx=0x7ff9a771db30, argv=<optimized out>) at connection.c:1449 #10 0x00000000004ee750 in ldap_int_thread_pool_wrapper (xpool=<optimized out>) at tpool.c:688 #11 0x00007ff9fc29f7b6 in start_thread () from /lib64/libpthread.so.0 #12 0x00007ff9fbffac5d in clone () from /lib64/libc.so.6 #13 0x0000000000000000 in ?? () 226 Transfer complete (unique file name:0001-Don-t-lock-other-threads-while-trying-to-connect-to.patch). Thread 258 (Thread 0x7ff9a6f1d700 (LWP 27086)): #0 0x00007ff9fbff1786 in poll () from /lib64/libc.so.6 #1 0x0000000000504b19 in ldap_int_poll (ld=0x5f03e030, s=462, tvp=0x7ff9a6f1afd0, wr=<optimized out>) at os-ip.c:302 #2 0x0000000000505248 in ldap_pvt_connect (async=<optimized out>, addrlen=<optimized out>, sin=<optimized out>, s=<optimized out>, ld=<optimized out>) at os-ip.c:465 #3 ldap_connect_to_host (ld=0x5f03e030, sb=0x592c0ed0, proto=1, srv=0x6e26edc0, async=0) at os-ip.c:658 #4 0x00000000004ef4d7 in ldap_int_open_connection (ld=0x5f03e030, conn=0x574bfc20, srv=0x6e26edc0, async=0) at open.c:367 #5 0x000000000050243a in ldap_new_connection (ld=0x5f03e030, srvlist=0x6cf79598, use_ldsb=1, connect=<optimized out>, bind=0x0, m_req=0, m_res=0) at request.c:481 #6 0x00000000004ef41f in ldap_open_defconn (ld=0x7ff9a6f1aef0) at open.c:41 #7 0x0000000000503158 in ldap_send_initial_request (ld=0x5f03e030, msgtype=<optimized out>, dn=<optimized out>, ber=0x6db20780, msgid=1) at request.c:130 #8 0x00000000004f8ebc in ldap_sasl_bind (ld=0x5f03e030, dn=0x89e9660 <error reading variable>, mechanism=0x0, cred=0x7ff9a6f1b220, sctrls=0x0, cctrls=<optimized out>, msgidp=0x7ff9a6f1b248) at sasl.c:148 #9 0x00000000004cb270 in meta_back_proxy_authz_bind (mc=0x12165ba0, candidate=2, op=0x342ac00, rs=0x7ff9a6f1ca60, sendok=LDAP_BACK_SENDERR, dolock=0) at bind.c:1582 #10 0x00000000004cb49f in meta_back_single_dobind (op=0x342ac00, rs=0x7ff9a6f1ca60, mcp=0x7ff9a6f1b560, candidate=2, sendok=LDAP_BACK_SENDERR, nretries=<optimized out>, dolock=0) at bind.c:605 #11 0x00000000004d5df3 in meta_back_retry (op=0x342ac00, rs=0x7ff9a6f1ca60, mcp=0x7ff9a6f1b560, candidate=2, sendok=LDAP_BACK_SENDERR) at conn.c:766 #12 0x00000000004b42c5 in meta_back_modify (op=0x342ac00, rs=0x7ff9a6f1ca60) at modify.c:194 #13 0x00000000004506d8 in fe_op_modify (op=0x342ac00, rs=0x7ff9a6f1ca60) at modify.c:303 #14 0x00000000004a0ef7 in overlay_op_walk (op=0x342ac00, rs=0x7ff9a6f1ca60, which=op_modify, oi=0x87cc000, on=0x0) at backover.c:671 #15 0x00000000004a1970 in over_op_func (op=0x342ac00, rs=0x7ff9a6f1a918, which=4000) at backover.c:723 #16 0x0000000000451007 in do_modify (op=0x342ac00, rs=0x7ff9a6f1ca60) at modify.c:177 #17 0x0000000000437eef in connection_operation (ctx=0x7ff9a6f1cb30, arg_v=<optimized out>) at connection.c:1313 #18 0x00000000004ee750 in ldap_int_thread_pool_wrapper (xpool=<optimized out>) at tpool.c:688 #19 0x00007ff9fc29f7b6 in start_thread () from /lib64/libpthread.so.0 #20 0x00007ff9fbffac5d in clone () from /lib64/libc.so.6 #21 0x0000000000000000 in ?? () Thread 257 (Thread 0x7ff9a671c700 (LWP 27088)): #0 0x00007ff9fc2a6294 in __lll_lock_wait () from /lib64/libpthread.so.0 #1 0x00007ff9fc2a1619 in _L_lock_1008 () from /lib64/libpthread.so.0 #2 0x00007ff9fc2a142e in pthread_mutex_lock () from /lib64/libpthread.so.0 #3 0x00000000004d4540 in meta_back_getconn (op=0x46fe000, rs=0x7ff9a671b930, candidate=0x0, sendok=LDAP_BACK_SENDERR) at conn.c:1129 #4 0x00000000004b5b61 in meta_back_search (op=0x46fe000, rs=0x7ff9a671b930) at search.c:803 #5 0x000000000043ab31 in fe_op_search (op=0x46fe000, rs=0x7ff9a671b930) at search.c:402 #6 0x00000000004a0ef7 in overlay_op_walk (op=0x46fe000, rs=0x7ff9a671b930, which=op_search, oi=0x87cc000, on=0x0) at backover.c:671 #7 0x00000000004a1970 in over_op_func (op=0x46fe000, rs=0x0, which=op_bind) at backover.c:723 #8 0x000000000043b37c in do_search (op=0x46fe000, rs=0x7ff9a671b930) at search.c:247 #9 0x0000000000437eef in connection_operation (ctx=0x7ff9a671bb30, arg_v=<optimized out>) at connection.c:1313 #10 0x0000000000438b1b in connection_read_thread (ctx=0x7ff9a671bb30, argv=<optimized out>) at connection.c:1449 #11 0x00000000004ee750 in ldap_int_thread_pool_wrapper (xpool=<optimized out>) at tpool.c:688 #12 0x00007ff9fc29f7b6 in start_thread () from /lib64/libpthread.so.0 #13 0x00007ff9fbffac5d in clone () from /lib64/libc.so.6 #14 0x0000000000000000 in ?? () Thread 256 (Thread 0x7ff9a5f1b700 (LWP 27089)): #0 0x00007ff9fc2a6294 in __lll_lock_wait () from /lib64/libpthread.so.0 #1 0x00007ff9fc2a1619 in _L_lock_1008 () from /lib64/libpthread.so.0 #2 0x00007ff9fc2a142e in pthread_mutex_lock () from /lib64/libpthread.so.0 #3 0x00000000004d4540 in meta_back_getconn (op=0x46f5000, rs=0x7ff9a5f1a930, candidate=0x0, sendok=LDAP_BACK_SENDERR) at conn.c:1129 #4 0x00000000004b5b61 in meta_back_search (op=0x46f5000, rs=0x7ff9a5f1a930) at search.c:803 #5 0x000000000043ab31 in fe_op_search (op=0x46f5000, rs=0x7ff9a5f1a930) at search.c:402 #6 0x00000000004a0ef7 in overlay_op_walk (op=0x46f5000, rs=0x7ff9a5f1a930, which=op_search, oi=0x87cc000, on=0x0) at backover.c:671 #7 0x00000000004a1970 in over_op_func (op=0x46f5000, rs=0x0, which=op_bind) at backover.c:723 #8 0x000000000043b37c in do_search (op=0x46f5000, rs=0x7ff9a5f1a930) at search.c:247 #9 0x0000000000437eef in connection_operation (ctx=0x7ff9a5f1ab30, arg_v=<optimized out>) at connection.c:1313 #10 0x0000000000438b1b in connection_read_thread (ctx=0x7ff9a5f1ab30, argv=<optimized out>) at connection.c:1449 #11 0x00000000004ee750 in ldap_int_thread_pool_wrapper (xpool=<optimized out>) at tpool.c:688 #12 0x00007ff9fc29f7b6 in start_thread () from /lib64/libpthread.so.0 #13 0x00007ff9fbffac5d in clone () from /lib64/libc.so.6 #14 0x0000000000000000 in ?? ()

1 0

Re: (ITS#7735) Memory leaks on Multi-Master replications
by dmitrii.fonariuk＠gmail.com 04 Nov '13

04 Nov '13

--047d7b33cb784de6d004ea68c04b Content-Type: text/plain; charset=ISO-8859-1 Hi Quanah, I have installed two patches, compiled binary and run modify requests test. I see that the memory is no longer leaking. great!!! patches helped. excellent work! Thanks! --Dmitrii --047d7b33cb784de6d004ea68c04b Content-Type: text/html; charset=ISO-8859-1 <div dir="ltr"><div class="gmail_extra"> <p class="MsoNormal">Hi Quanah,</p><p class="MsoNormal"><br></p><p class="MsoNormal">I have installed two patches, compiled binary and run modify requests test. I see that the memory is no longer leaking. great!!! patches helped. excellent work!</p><p class="MsoNormal"> </p><p class="MsoNormal"><br></p><p class="MsoNormal">Thanks!</p><p class="MsoNormal"><br></p><p class="MsoNormal">--Dmitrii</p> </div></div> --047d7b33cb784de6d004ea68c04b--

1 0

Re: (ITS#7739) Include of include badly handled while converting from slapd.conf to slapd.d
by hyc＠symas.com 04 Nov '13

04 Nov '13

raphael.ouazana(a)linagora.com wrote: > Full_Name: Raphael Ouazana > Version: 2.4.37 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (88.173.78.196) > > > Hi, > > If I have for example a main slapd.conf with: > include <path>schema.conf > > And a simple schema.conf: > include <path>core.schema > include <path>cosine.schema > include <path>inetorgperson.schema > > When I try to convert slapd.conf to slapd.d with slaptest, the resulting > configuration is incorrect: the schema file are not included. > Try again, using a different name than "schema.conf" -- -- 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#7739) Include of include badly handled while converting from slapd.conf to slapd.d
by raphael.ouazana＠linagora.com 04 Nov '13

04 Nov '13

Full_Name: Raphael Ouazana Version: 2.4.37 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (88.173.78.196) Hi, If I have for example a main slapd.conf with: include <path>schema.conf And a simple schema.conf: include <path>core.schema include <path>cosine.schema include <path>inetorgperson.schema When I try to convert slapd.conf to slapd.d with slaptest, the resulting configuration is incorrect: the schema file are not included. Regards, Raphaël Ouazana.

1 0

Re: (ITS#7723) slapd crashes on multi core machines if a search request is *immediately* followed by an unbind
by hyc＠symas.com 04 Nov '13

04 Nov '13

jsynacek(a)redhat.com wrote: > On 10/15/2013 01:10 PM, michael.vishchers(a)7p-group.com wrote: >> It is not the client loop that is multithreading but the ldap server. >> >> And it is not a misuse of the API but a problem that may be raised by day t= >> o day network problems. >> >> I've boiled down the problem to a few simple configurations that work (or b= >> etter, fail ;-) with both 2.4.23 and 2.4.36. A tgz file containing a setup = >> with start script and testclient is attached. It should be sufficient to re= >> produce the fault. >> >> The problem occurs only if we use session variable substitution in the rwm = >> overlay, and only if a search is *immediately* (e.g. caused by network loss= >> and client timeout) followed by an unbind. >> > > I modified the reproducer a bit (the start script) and find out a few things. > You can find the reproducer I'm using at [1]. > > Valgrind's helgrind shows some lock problems in the rwm overlay and also in > back-ldap and connection.c. After correcting those the issue seems to be gone. > > You can find helgrind logs at [2] (before the fix) and [3] (after). > > Also, ElectricFence reveals some problems [4], which I didn't fix yet. > > A fix attempt can be found at [5]. I'm not sure if that is a correct fix, or it > just masked the real issue. But I didn't to manage to reproduce the problem > after applying it. I already explained the problem. The other issues you identified are not relevant, and your patch is not correct. Reread Followup #4 of 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#7723) slapd crashes on multi core machines if a search request is *immediately* followed by an unbind
by jsynacek＠redhat.com 04 Nov '13

04 Nov '13

On 10/15/2013 01:10 PM, michael.vishchers(a)7p-group.com wrote: > It is not the client loop that is multithreading but the ldap server. > > And it is not a misuse of the API but a problem that may be raised by day t= > o day network problems. > > I've boiled down the problem to a few simple configurations that work (or b= > etter, fail ;-) with both 2.4.23 and 2.4.36. A tgz file containing a setup = > with start script and testclient is attached. It should be sufficient to re= > produce the fault. > > The problem occurs only if we use session variable substitution in the rwm = > overlay, and only if a search is *immediately* (e.g. caused by network loss= > and client timeout) followed by an unbind. > I modified the reproducer a bit (the start script) and find out a few things. You can find the reproducer I'm using at [1]. Valgrind's helgrind shows some lock problems in the rwm overlay and also in back-ldap and connection.c. After correcting those the issue seems to be gone. You can find helgrind logs at [2] (before the fix) and [3] (after). Also, ElectricFence reveals some problems [4], which I didn't fix yet. A fix attempt can be found at [5]. I'm not sure if that is a correct fix, or it just masked the real issue. But I didn't to manage to reproduce the problem after applying it. [1] http://jsynacek.fedorapeople.org/openldap/its7723/reproducer/ [2] http://jsynacek.fedorapeople.org/openldap/its7723/results/slapd1-helgrind-b… [3] http://jsynacek.fedorapeople.org/openldap/its7723/results/slapd1-helgrind-f… [4] http://jsynacek.fedorapeople.org/openldap/its7723/results/slapd1-broken-efe… [5] http://jsynacek.fedorapeople.org/openldap/its7723/0001-fix-possible-race-co… Cheers, -- Jan Synacek Software Engineer, Red Hat

1 0

Re: (ITS#7735) Memory leaks on Multi-Master replications
by quanah＠zimbra.com 02 Nov '13

02 Nov '13

--On Friday, November 01, 2013 10:39 PM +0400 Dmitrii Fonariuk <dmitrii.fonariuk(a)gmail.com> wrote: > > > hi Quanah, > > it's a good news! unfortunately I can't test the changes now. Tuesday I > rebuild the source with patch, do the tests and report to you. > > thank you for your efforts. You will also need to grab <http://www.openldap.org/devel/gitweb.cgi?p=openldap.git;a=patch;h=ed0922296…> --Quanah -- Quanah Gibson-Mount Architect - Server Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#7700) DOC: OL AdminGuide not updated
by marco.pizzoli＠gmail.com 02 Nov '13

02 Nov '13

On Sat, Nov 2, 2013 at 10:56 PM, Gavin Henry <openldap-its(a)openldap.org> wrote: >> I noticed other errors on the Admin Guide. > > Hi Marco, > > Many thanks for taking the time to read our documentation and report missing > items and errors. It's been a pleasure :-) [cut] >> 6.2.3.3 -> I think it could be useful to specify that in case that >> server is consumer, all modifications coming from syncrepl still >> continue to be received and written > > Do you have any more wording you'd like to contribute as per: > > http://www.openldap.org/devel/contributing.html I'm afraid I cannot get what you are asking me to do. Are you asking me to just add the disclaimer or to reword my point in order to be feasible for direct inclusion in the AdminGuide? > >> 6.2.3.6 -> "Note: When the backend to pass a query to is selected, >> slapd looks at the suffix line(s) in each database definition in the >> order they appear in the file. >> Thus, if one database suffix is a prefix of another, it must >> appear BEFORE it in the config file." > > And with the ldif backend for dynamic configuration, cn=config Of course :-) And what if I found errors also on this page? :-) http://www.openldap.org/devel/contributing.html#patches "Each software change should be conCise, self-contained, and made against up-to-date source code." "One patch per functional change, and" -> and what? Regards Marco

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