openldap-bugs

openldap-bugs@openldap.org

1 participants
20960 discussions

Re: (ITS#4780) ACL set memory leak
by hyc＠symas.com 20 Dec '06

20 Dec '06

dhawes(a)vt.edu wrote: > On Saturday 16 December 2006 08:54, ando(a)sys-net.it wrote: >> dhawes(a)vt.edu wrote: >>> I notice the same behavior on 2.3.27, but did not notice it with older >>> versions such as 2.2.26. >> I can't confirm this issue neither with HEAD nor with re23; I used >> valgrind and the set string you posted verbatim, although I didn't use >> slamd. However, right now I don't see how it may be a matter of >> concurrency. > > I notice the same behavior with 2.3.31 as well. From my testing 2.2.30 does > not exhibit this behavior while 2.3.4 (and later) does. I've also been unable to reproduce this. Can you run using valgrind or some other malloc tracer and get some diagnostics? -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/

1 0

Re: (ITS#4780) ACL set memory leak
by dhawes＠vt.edu 20 Dec '06

20 Dec '06

On Saturday 16 December 2006 08:54, ando(a)sys-net.it wrote: > dhawes(a)vt.edu wrote: > > When using ACL sets, OpenLDAP 2.3.30 steadily uses up all the system > > memory before crashing (slapd: ch_malloc.c:57: ch_malloc: Assertion `0' > > failed). > > > > The system is loaded using SLAMD with 4 clients doing anonymous searches > > on a filter file of approximately 300,000 filters (taken from a typical > > day on a production server). SLAMD reports that 2885650 entries are > > returned in the 30 minutes it takes to use up all available memory (4G). > > > > The instance contains approximately 1 million entries in a bdb backend, > > and uses the following simple set of ACLs for this test: > > > > ... > > access to dn.base="" > > by * read > > > > access to dn.base="cn=Subschema" > > by * read > > > > access to dn.base="dc=example,dc=com" > > by * read > > > > access to dn.base="ou=People,dc=example,dc=com" > > by * read > > > > access to * > > by set="[string1] & [string2]" read > > by peername.ip=<slamd client ip 1> read > > by peername.ip=<slamd client ip 2> read > > by peername.ip=<slamd client ip 3> read > > by peername.ip=<slamd client ip 4> read > > by * none > > ... > > > > Removing the "by set=" clause and running the SLAMD job causes OpenLDAP > > memory usage to stabilize. > > > > I notice the same behavior on 2.3.27, but did not notice it with older > > versions such as 2.2.26. > > I can't confirm this issue neither with HEAD nor with re23; I used > valgrind and the set string you posted verbatim, although I didn't use > slamd. However, right now I don't see how it may be a matter of > concurrency. I notice the same behavior with 2.3.31 as well. From my testing 2.2.30 does not exhibit this behavior while 2.3.4 (and later) does. dave

1 0

Re: (ITS#4782) back-ldap bugs
by ando＠sys-net.it 19 Dec '06

19 Dec '06

hyc(a)OpenLDAP.org wrote: > 1) back-ldap fails to startup if back-monitor isn't enabled. It should silently > skip usage of back-monitor, the way back-bdb does. > should be fixed now (not quite clean, though) > 2) multiple calls are made to ldap_back_is_proxy_authz with > sendok=LDAP_BACK_SENDERR without checking the return status or aborting the > operation. As such, when proxy authorization is not in effect for an operation, > the client receives multiple Error Result messages for its request (even though > it continues to completion). This should be fixed now, thanks for pointing out. > Likewise for ldap_back_proxy_authz_bind. Here the fix is slightly different: whenever ldap_back_proxy_authz_bind() succeeds, it should set rc to 1; this is the actual error. > Either > these functions should never send a result back to the client, or their return > status should be checked and processing should stop when they fail. I've cleaned > up several instances of this type of error in previous revisions but can't track > them all down now. Errors of this type may also exist in RE23; I haven't > looked. > There shouldn't be too many, as that stuff was only recently reworked. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.n.c. Via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ------------------------------------------ Office: +39.02.23998309 Mobile: +39.333.4963172 Email: pierangelo.masarati(a)sys-net.it ------------------------------------------

1 0

Re: (ITS#4782) back-ldap bugs
by ando＠sys-net.it 19 Dec '06

19 Dec '06

hyc(a)symas.com wrote: > In my case, all backends are dynamic modules, and back-monitor was not > loaded. > OK. In my intentions, back-monitor shouldn't be a module; it should be statically built-in, much like back-ldif and back-config, although the requirement might be less strict. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.n.c. Via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ------------------------------------------ Office: +39.02.23998309 Mobile: +39.333.4963172 Email: pierangelo.masarati(a)sys-net.it ------------------------------------------

1 0

Re: (ITS#4782) back-ldap bugs
by hyc＠symas.com 19 Dec '06

19 Dec '06

Pierangelo Masarati wrote: > hyc(a)OpenLDAP.org wrote: >> Full_Name: Howard Chu >> Version: HEAD >> OS: URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (76.168.84.21) >> Submitted by: hyc >> >> >> 1) back-ldap fails to startup if back-monitor isn't enabled. It should >> silently >> skip usage of back-monitor, the way back-bdb does. >> > That's what's supposed to do. Do you mean back-monitor "compiled" or > "instantiated"? "Compiled" should be moot, as back-monitor should now > be always compiled. In my case, all backends are dynamic modules, and back-monitor was not loaded. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/

1 0

Re: (ITS#4782) back-ldap bugs
by ando＠sys-net.it 19 Dec '06

19 Dec '06

hyc(a)OpenLDAP.org wrote: > Full_Name: Howard Chu > Version: HEAD > OS: > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (76.168.84.21) > Submitted by: hyc > > > 1) back-ldap fails to startup if back-monitor isn't enabled. It should silently > skip usage of back-monitor, the way back-bdb does. > That's what's supposed to do. Do you mean back-monitor "compiled" or "instantiated"? "Compiled" should be moot, as back-monitor should now be always compiled. > 2) multiple calls are made to ldap_back_is_proxy_authz with > sendok=LDAP_BACK_SENDERR without checking the return status or aborting the > operation. As such, when proxy authorization is not in effect for an operation, > the client receives multiple Error Result messages for its request (even though > it continues to completion). Likewise for ldap_back_proxy_authz_bind. Either > these functions should never send a result back to the client, or their return > status should be checked and processing should stop when they fail. I've cleaned > up several instances of this type of error in previous revisions but can't track > them all down now. Errors of this type may also exist in RE23; I haven't > looked. > I've been cleaning up some of those in back-ldap (and in back-meta as well); some might have slipped thru. Thanks, p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.n.c. Via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ------------------------------------------ Office: +39.02.23998309 Mobile: +39.333.4963172 Email: pierangelo.masarati(a)sys-net.it ------------------------------------------

1 0

(ITS#4782) back-ldap bugs
by hyc＠OpenLDAP.org 19 Dec '06

19 Dec '06

Full_Name: Howard Chu Version: HEAD OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (76.168.84.21) Submitted by: hyc 1) back-ldap fails to startup if back-monitor isn't enabled. It should silently skip usage of back-monitor, the way back-bdb does. 2) multiple calls are made to ldap_back_is_proxy_authz with sendok=LDAP_BACK_SENDERR without checking the return status or aborting the operation. As such, when proxy authorization is not in effect for an operation, the client receives multiple Error Result messages for its request (even though it continues to completion). Likewise for ldap_back_proxy_authz_bind. Either these functions should never send a result back to the client, or their return status should be checked and processing should stop when they fail. I've cleaned up several instances of this type of error in previous revisions but can't track them all down now. Errors of this type may also exist in RE23; I haven't looked.

1 0

Re: (ITS#4774) Add network timeout option to ldapsearch
by lukeh＠padl.com 18 Dec '06

18 Dec '06

Kurt, >Given this, -e nettimeout=X might be better choice here. >Or -o nettimeout=X. Agreed. I have prepared a patch for the following which I will commit to HEAD: -o <opt>[=<optparam] general options nettimeout=<timeout> (in seconds, or "none" or "max") -- Luke -- www.padl.com | www.lukehoward.com

1 0

Re: (ITS#4585) slapd-search generates TIME_WAIT connections increasingly
by ando＠sys-net.it 18 Dec '06

18 Dec '06

Roland, Howard pointed out that part of your problem could be related to the fact that AD makes an intensive use of referrals, and automatic referral chasing with OpenLDAP's client library was buggy (ITS#4545). A fix to this issue will appear in OpenLDAP 2.3.31; you can get the corresponding code from the CVS under the tag OPENLDAP_REL_ENG_2_3, or wait a few days for the official release. Could you please check if your problem persists with this release? p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.n.c. Via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ------------------------------------------ Office: +39.02.23998309 Mobile: +39.333.4963172 Email: pierangelo.masarati(a)sys-net.it ------------------------------------------

1 0

(ITS#4781) optimize bind behavior in back-ldap when idassert is in use
by ando＠sys-net.it 17 Dec '06

17 Dec '06

Full_Name: Pierangelo Masarati Version: HEAD OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (81.72.89.40) Submitted by: ando When idassert is used with "override" (i.e. it occurs also when the instance of back-ldap is the authorizing backend) and it is going to accept to authorize any identity, there is no need to create/destroy a connection for each bind, since subsequent operations will ever occur on the privileged, cached connection with identity assertion. So a separate cached connection is used only for binds, which of course need to be serialized (i.e. wait for response before submitting another one). Here there's room for further optimization: in case the connection is busy waiting for response, back-ldap can either wait or use a temporary (the original behavior). Further optimization will allow a pool of dedicated connections to alleviate concurrency issues. A patch is coming. p.

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