openldap-bugs

openldap-bugs@openldap.org

1 participants
20960 discussions

(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 20 Dec '06

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

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

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

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

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

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

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

20 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

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