Re: (ITS#4783) ldap_sasl_bind() is not asynchronous
by fcusack＠fcusack.com
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
16 years, 1 month
Re: (ITS#4780) ACL set memory leak
by dhawes＠vt.edu
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
16 years, 1 month
Re: (ITS#4783) ldap_sasl_bind() is not asynchronous
by Kurt＠OpenLDAP.org
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
16 years, 1 month
Re: (ITS#4780) ACL set memory leak
by hyc＠symas.com
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/
16 years, 1 month
Re: (ITS#4780) ACL set memory leak
by dhawes＠vt.edu
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
16 years, 1 month
Re: (ITS#4782) back-ldap bugs
by ando＠sys-net.it
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
------------------------------------------
16 years, 1 month
Re: (ITS#4782) back-ldap bugs
by ando＠sys-net.it
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
------------------------------------------
16 years, 1 month
Re: (ITS#4782) back-ldap bugs
by hyc＠symas.com
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/
16 years, 1 month
