openldap-bugs

openldap-bugs@openldap.org

1 participants
20953 discussions

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

20 Dec '06

On December 20, 2006 9:18:18 AM +0100 Pierangelo Masarati <ando(a)sys-net.it> wrote: > fcusack(a)fcusack.com wrote: >> 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. >> > There was a discussion recently on the subject (look in hte ITS). A bind > cannot be abandoned as per RFC 4511-19; you need to ldap_unbind_ext and > recreate a fresh connection. OK, I see that abandon isn't really the right thing here. But still you can do the bind async, and just close the fd on the client side on timeout. I don't see why connect() timeout can't be handled the same way. (ignoring the problem that there is no API call AFAICT to just drop the connection) -frank

1 0

(ITS#4786) back-sql searching with dn attribute selected causes object class violation
by robb＠wtg.cw.com 20 Dec '06

20 Dec '06

Full_Name: Robert Brooks Version: 2.3.31 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (62.49.19.14) an ldapsearch like this works ldapsearch -x -b "dc=sql,dc=example,dc=org" "cn=Robert Brooks" cn dn: uid=robb(a)example.org,dc=sql,dc=example,dc=org cn: Robert Brooks # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1 however this does not: ldapsearch -x -b "dc=sql,dc=example,dc=org" "cn=Robert Brooks" dn cn # search result search: 2 result: 65 Object class violation # numResponses:

1 0

(ITS#4785) back-sql objectclass searches fail unless there is data in ldap_entry_objclasses
by robb＠wtg.cw.com 20 Dec '06

20 Dec '06

Full_Name: Robert Brooks Version: 2.3.31 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (62.49.19.14) objectclass searches fail (with back-sql/mysql) if there is no data in the ldap_entry_objclasses table. Just a simple dummy entry like this is enough to fix the problem. +----------+----------+ | entry_id | oc_name | +----------+----------+ | 0 | dcObject | +----------+----------+

1 0

(ITS#4784) a small patch for back-sql
by robb＠wtg.cw.com 20 Dec '06

20 Dec '06

Full_Name: Robert Brooks Version: 2.3.31 OS: Linux URL: ftp://ftp.openldap.org/incoming/openldap-2.3.30-tracesql.patch Submission from: (NULL) (62.49.19.14) back-sql fails to compile with BACKSQL_TRACE defined, I think this is the correct fix.

1 0

Re: (ITS#4783) ldap_sasl_bind() is not asynchronous
by ando＠sys-net.it 20 Dec '06

20 Dec '06

fcusack(a)fcusack.com wrote: > 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. > There was a discussion recently on the subject (look in hte ITS). A bind cannot be abandoned as per RFC 4511-19; you need to ldap_unbind_ext and recreate a fresh connection. > I am not all that familiar with the LDAP API, so forgive me if I'm > way off base here. > 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#4780) ACL set memory leak
by dhawes＠vt.edu 19 Dec '06

19 Dec '06

On Tuesday 19 December 2006 23:42, hyc(a)symas.com wrote: > David Hawes wrote: > > 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: > > Try the patch in HEAD sets.c 1.29 -> 1.30. I haven't tested the patch with valgrind yet, but I no longer see the memory leak with my SLAMD test. Thanks for your help with this. dave

1 0

ITS#3971 slapo-glue and slapo-rwm
by hyc＠symas.com 19 Dec '06

19 Dec '06

This issue has been fixed in HEAD with the patches for ITS#4638. This ITS will be closed in favor of #4638. -- -- 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 hyc＠symas.com 19 Dec '06

19 Dec '06

David Hawes wrote: > 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: Try the patch in HEAD sets.c 1.29 -> 1.30. -- -- 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#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

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