openldap-bugs December 2006

openldap-bugs@openldap.org

23 participants
120 discussions

Re: (ITS#4783) ldap_sasl_bind() is not asynchronous
by fcusack＠fcusack.com 19 Dec '06

19 Dec '06

On December 19, 2006 7:04:15 PM -0800 "Kurt D. Zeilenga" <Kurt(a)OpenLDAP.org> wrote: > At 05:32 PM 12/19/2006, fcusack(a)fcusack.com wrote: >> Full_Name: Frank Cusack >> Version: 2.3.27 >> OS: any >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (209.76.127.62) >> >> connect() is always done synchronously. Any idea when this will be >> fixed? > > It's actually not considered a bug. ldap_sasl_bind(3) is async > in doesn't wait for the LDAP response. There is no LDAP restart > API, as would be needed if the API didn't block on various > system calls. Why is that required here? ldap_sasl_bind() ldap_result() if (timeout) { ldap_abandon() if (just_return_on_error) { return error } else { do_something_else } } To restart a bind, just abandon and bind again. I am not all that familiar with the LDAP API, so forgive me if I'm way off base here. -frank

1 0

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

19 Dec '06

On Tuesday 19 December 2006 19:39, hyc(a)symas.com wrote: > 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? Absolutely. Here's the valgrind output with the set clause in place: http://filebox.vt.edu/users/dhawes/valgrind-with-set.log Here's the valgrind output without the set clause (for reference): http://filebox.vt.edu/users/dhawes/valgrind-without-set.log The following patch causes memory use to stabilize with my SLAMD test: --- openldap-2.3.31-orig/servers/slapd/sets.c 2006-01-03 17:16:15.000000000 -0500 +++ openldap-2.3.31/servers/slapd/sets.c 2006-12-19 21:37:40.000000000 -0500 @@ -440,6 +440,7 @@ AC_MEMCPY( set->bv_val, &filter[ - len - 1 ], len ); set->bv_len = len; SF_PUSH( set ); + cp->set_op->o_tmpfree( set->bv_val, cp->set_op->o_tmpmemctx ); set = NULL; break; Of course, this patch makes sets useless, so it's hardly a fix. I'm still looking at the code to determine what's going on here--I'm sure you guys will be able to pinpoint it in an instant. dave

1 0

Re: (ITS#4783) ldap_sasl_bind() is not asynchronous
by Kurt＠OpenLDAP.org 19 Dec '06

19 Dec '06

At 05:32 PM 12/19/2006, fcusack(a)fcusack.com wrote: >Full_Name: Frank Cusack >Version: 2.3.27 >OS: any >URL: ftp://ftp.openldap.org/incoming/ >Submission from: (NULL) (209.76.127.62) > >connect() is always done synchronously. Any idea when this will be fixed? It's actually not considered a bug. ldap_sasl_bind(3) is async in doesn't wait for the LDAP response. There is no LDAP restart API, as would be needed if the API didn't block on various system calls. So the first step in "fixing" this would be to design an LDAP restart API... yet another reason to redesign the whole API... Kurt

1 0

Re: (ITS#4783) ldap_sasl_bind() is not asynchronous
by hyc＠symas.com 19 Dec '06

19 Dec '06

fcusack(a)fcusack.com wrote: > Full_Name: Frank Cusack > Version: 2.3.27 > OS: any > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (209.76.127.62) > > > connect() is always done synchronously. Any idea when this will be fixed? You're welcome to submit a patch. -- -- 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

(ITS#4783) ldap_sasl_bind() is not asynchronous
by fcusack＠fcusack.com 19 Dec '06

19 Dec '06

Full_Name: Frank Cusack Version: 2.3.27 OS: any URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (209.76.127.62) connect() is always done synchronously. Any idea when this will be fixed?

1 0

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

19 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 19 Dec '06

19 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

← Newer
1
2
3
4
5
6
7
8
...
12
Older →

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs December 2006