Re: (ITS#6453) OpenLDAP memory leak on LDAP_TIMEOUT
by alinachegalati＠yahoo.com
--0-1691785669-1266069835=:3216
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Hi Serghei,
=A0
=A0=A0 I am using OpenLdap 2.4.19. By examining the change log i don't see =
any behaviour=A0 change for ldap_search functions against 2.4.16.
=A0
=A0 My application is already multithreaded. Different search requests come=
in the same time=A0and multiple threads are usedfor this. There is an ldap=
connection pool in place, a thread will pick up a free connection, will us=
e it for search and return it back to the pool.
=A0
=A0 I used the sync api because I looked over the OpenLdap source code and =
the sync api is based on the async one.=A0While waiting for a meesage, the =
async api will examine the abandoned results and destroy them. However it l=
ooks like this behaviour doesn't work very well.=A0
=A0
=A0 You mentioned "But you can filter itby using ldap_msgtype() and killing=
the results for searches only." Can you provide a piece of code for that?
=A0
Thanks,
Alin
=A0
--- On Sat, 2/13/10, linamat(a)telco.md <linamat(a)telco.md> wrote:
From: linamat(a)telco.md <linamat(a)telco.md>
Subject: Re: (ITS#6453) OpenLDAP memory leak on LDAP_TIMEOUT
To: alinachegalati(a)yahoo.com
Date: Saturday, February 13, 2010, 4:44 AM
>
> Sorry, it is my fault here. I missed the trailling "s"...
>
> I am using the OpenLDAP api only for searching for ldap entries on a
different LDAP serve (I am not aware of its type).=A0 So the only
libraries linked to my app are libldap_r.so and liblber.so.
>
And what version of library?
I am using 2.4.16.
> I don' have access to the source code now but I'll post a section of it
soon.
>
You are welcome;)
> The idea of using ldap_result with LDAP_RES_ANY is interesting. Do you
>know what is the difference between LDAP_RES_ANY and
LDAP_RES_UNSOLICITED?
The answer is on
http://www.openldap.org/lists/openldap-technical/200912/msg00007.html
As I know LDAP_RES_ANY includes search results too. But you can filter it
by using ldap_msgtype() and killing the results for searches only.
>I'm thinking to create a separate daemon thread that takes
> ldap_connections from the pool and makes this call. My main concern is
not >to clash with the existing results.
>
Good aproach. But if you should switch to asyncronous version of calls,
you could beep the horn during periods of waiting for results withing one
thread.
> I'll try this solution and let you know how it worked.
>
> Regards,
> Alin
>
>
> --- On Sat, 2/13/10, linamat(a)telco.md <linamat(a)telco.md> wrote:
>
>
> From: linamat(a)telco.md <linamat(a)telco.md>
> Subject: Re: (ITS#6453) OpenLDAP memory leak on LDAP_TIMEOUT
> To: alinachegalati(a)yahoo.com
> Date: Saturday, February 13, 2010, 12:52 AM
>
>
>>
>>=A0 =A0 =A0 For the first point, the function ldap_msgfree=A0 will check =
for
> NULL, > so if the check is missing, no error occurs.
>>
>
> I believe the pointer should be checked for NULL just to be safe in
cases when implementation suddenly changes.
>
>>=A0 =A0=A0=A0I am using the ldap_search_ext_s function (the synchronous o=
ne) so
> the >second and third point doesn't apply as i don't have access to the
msgid. >If the memory leak is high maybe will switch to the
> async queries.
>> Regards,
>> Alin
>
> You wrote "We have a memory leak LDAP_TIMEOUT is encountered on
> ldap_search_ext_invocation". It not clear if sync or async primitive is
used. If ldap_search_ext_s is used then general timeout set per
> LDAPConnection is aplied. May be ldap_search_ext_st is better for use.
>
> As to point 3 it can be applied in your case for checking and destroying
pending or timed out operations.
>
> I am currently using openldap in different applications on Solaris
x86/x64/sparc=A0=A0=A0both 32-bit and 64 without any troubles. Also we need=
to
mention that you can try libldap for version 2.4.16 as it seems to be
rock stable and free of this issues. Also if you are using dbd backend,
dbd must be 4.7.25 + 4 patches recommended by Oracle.
>
> You could post the code block for verifying.
>
> With respect, Serghei.
>
>>
>>
>>
>>
>> --- On Fri, 2/12/10, linamat(a)telco.md <linamat(a)telco.md> wrote:
>>
>>
>> From: linamat(a)telco.md <linamat(a)telco.md>
>> Subject: Re: (ITS#6453) OpenLDAP memory leak on LDAP_TIMEOUT
>> To: openldap-its(a)OpenLDAP.org
>> Cc: alinachegalati(a)yahoo.com
>> Date: Friday, February 12, 2010, 1:34 PM
>>
>>
>> Buna ziua, domnule.
>>
>> 1. The pointer must be checked before operation, e.g.
>> if (res !=3D NULL) {
>>=A0 =A0=A0=A0ldap_msgfree (res);
>>=A0 =A0=A0=A0res =3D NULL;
>> }
>>
>> 2. Also while processing the ext query, you should call the functions in
> the following manner:
>> 2.1 ldap_search_ext() which has pointer to msgid
>> 2.2 ldap_result() which gives the LDAPMessage structure for the msgid
> 2.3 if ok - ldap_parse_result()
>> 2.4 on any stage if something is not good and you have the msgid filled
> with value (integer, typicaly more then 1) you should call
>> ldap_abandon_ext() for that msgid
>> 2.5 Finish with ldap_msgfree()
>>
>> 3. Periodically between the asynchronous searches (after 100 for
> example)you should call ldap_result() with short timer and LDAP_RES_ANY
argue for clearing stalled or nonfreed calls. The obtained LDAPMessage
can be freed with ldap_msgfree(). Of course, you can count the asynch
calls which hadn't been completed or were timed out and you can make the
corresponding cycle for checking all iterations.
>>
>> Please try and let me know.
>>
>> With respect, Serghei.
>>
>>
>>
>>
>>
>
>
>
>
>
>
=0A=0A=0A
--0-1691785669-1266069835=:3216
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
<table cellspacing=3D"0" cellpadding=3D"0" border=3D"0" ><tr><td valign=3D"=
top" style=3D"font: inherit;"><DIV><BR>Hi Serghei,</DIV>
<DIV> </DIV>
<DIV> I am using OpenLdap 2.4.19. By examining the change log i=
don't see any behaviour change for ldap_search functions against 2.4=
.16.</DIV>
<DIV> </DIV>
<DIV> My application is already multithreaded. Different search reque=
sts come in the same time and multiple threads are usedfor this. There=
is an ldap connection pool in place, a thread will pick up a free connecti=
on, will use it for search and return it back to the pool.</DIV>
<DIV> </DIV>
<DIV> I used the sync api because I looked over the OpenLdap source c=
ode and the sync api is based on the async one. While waiting for a me=
esage, the async api will examine the abandoned results and destroy them. H=
owever it looks like this behaviour doesn't work very well. </DIV>
<DIV> </DIV>
<DIV> You mentioned "But you can filter itby using ldap_msgtype() and=
killing the results for searches only." Can you provide a piece of code fo=
r that?</DIV>
<DIV> </DIV>
<DIV>Thanks,</DIV>
<DIV>Alin<BR></DIV>
<DIV> </DIV>
<DIV>--- On <B>Sat, 2/13/10, linamat(a)telco.md <I><linamat(a)telco.md></=
I></B> wrote:<BR></DIV>
<BLOCKQUOTE style=3D"BORDER-LEFT: rgb(16,16,255) 2px solid; PADDING-LEFT: 5=
px; MARGIN-LEFT: 5px"><BR>From: linamat(a)telco.md <linamat(a)telco.md><B=
R>Subject: Re: (ITS#6453) OpenLDAP memory leak on LDAP_TIMEOUT<BR>To: alina=
chegalati(a)yahoo.com<BR>Date: Saturday, February 13, 2010, 4:44 AM<BR><BR>
<DIV class=3DplainMail>><BR>> Sorry, it is my fault here. I missed th=
e trailling "s"...<BR>><BR>> I am using the OpenLDAP api only for sea=
rching for ldap entries on a<BR>different LDAP serve (I am not aware of its=
type). So the only<BR>libraries linked to my app are libldap_r.so an=
d liblber.so.<BR>><BR><BR>And what version of library?<BR>I am using 2.4=
.16.<BR><BR>> I don' have access to the source code now but I'll post a =
section of it<BR>soon.<BR>><BR><BR>You are welcome;)<BR><BR>> The ide=
a of using ldap_result with LDAP_RES_ANY is interesting. Do you<BR>>know=
what is the difference between LDAP_RES_ANY and<BR>LDAP_RES_UNSOLICITED?<B=
R><BR>The answer is on<BR><A href=3D"http://www.openldap.org/lists/openldap=
-technical/200912/msg00007.html" target=3D_blank>http://www.openldap.org/li=
sts/openldap-technical/200912/msg00007.html</A><BR><BR>As I know LDAP_RES_A=
NY includes search results too. But you can filter it<BR>by using
ldap_msgtype() and killing the results for searches only.<BR><BR>>I'm t=
hinking to create a separate daemon thread that takes<BR>> ldap_connecti=
ons from the pool and makes this call. My main concern is<BR>not >to cla=
sh with the existing results.<BR>><BR><BR>Good aproach. But if you shoul=
d switch to asyncronous version of calls,<BR>you could beep the horn during=
periods of waiting for results withing one<BR>thread.<BR><BR>> I'll try=
this solution and let you know how it worked.<BR>><BR>> Regards,<BR>=
> Alin<BR>><BR>><BR>> --- On Sat, 2/13/10, <A href=3D"http://us=
.mc507.mail.yahoo.com/mc/compose?to=3Dlinamat(a)telco.md" ymailto=3D"mailto:l=
inamat(a)telco.md">linamat(a)telco.md</A> <<A href=3D"http://us.mc507.mail.y=
ahoo.com/mc/compose?to=3Dlinamat@telco.md" ymailto=3D"mailto:linamat@telco.=
md">linamat(a)telco.md</A>> wrote:<BR>><BR>><BR>> From: <A href=
=3D"http://us.mc507.mail.yahoo.com/mc/compose?to=3Dlinamat@telco.md"
ymailto=3D"mailto:linamat@telco.md">linamat(a)telco.md</A> <<A href=3D"ht=
tp://us.mc507.mail.yahoo.com/mc/compose?to=3Dlinamat@telco.md" ymailto=3D"m=
ailto:linamat@telco.md">linamat(a)telco.md</A>><BR>> Subject: Re: (ITS#=
6453) OpenLDAP memory leak on LDAP_TIMEOUT<BR>> To: <A href=3D"http://us=
.mc507.mail.yahoo.com/mc/compose?to=3Dalinachegalati(a)yahoo.com" ymailto=3D"=
mailto:alinachegalati@yahoo.com">alinachegalati(a)yahoo.com</A><BR>> Date:=
Saturday, February 13, 2010, 12:52 AM<BR>><BR>><BR>>><BR>>&=
gt; For the first point, the function ldap_msgfree =
; will check for<BR>> NULL, > so if the check is missing, no error oc=
curs.<BR>>><BR>><BR>> I believe the pointer should be checked f=
or NULL just to be safe in<BR>cases when implementation suddenly changes.<B=
R>><BR>>> I am using the ldap_search_ext_s=
function (the synchronous one) so<BR>> the >second and third point d=
oesn't
apply as i don't have access to the<BR>msgid. >If the memory leak is hi=
gh maybe will switch to the<BR>> async queries.<BR>>> Regards,<BR>=
>> Alin<BR>><BR>> You wrote "We have a memory leak LDAP_TIMEOUT=
is encountered on<BR>> ldap_search_ext_invocation". It not clear if syn=
c or async primitive is<BR>used. If ldap_search_ext_s is used then general =
timeout set per<BR>> LDAPConnection is aplied. May be ldap_search_ext_st=
is better for use.<BR>><BR>> As to point 3 it can be applied in your=
case for checking and destroying<BR>pending or timed out operations.<BR>&g=
t;<BR>> I am currently using openldap in different applications on Solar=
is<BR>x86/x64/sparc both 32-bit and 64 without any trouble=
s. Also we need to<BR>mention that you can try libldap for version 2.4.16 a=
s it seems to be<BR>rock stable and free of this issues. Also if you are us=
ing dbd backend,<BR>dbd must be 4.7.25 + 4 patches recommended by
Oracle.<BR>><BR>> You could post the code block for verifying.<BR>&g=
t;<BR>> With respect, Serghei.<BR>><BR>>><BR>>><BR>>&g=
t;<BR>>><BR>>> --- On Fri, 2/12/10, <A href=3D"http://us.mc507.=
mail.yahoo.com/mc/compose?to=3Dlinamat@telco.md" ymailto=3D"mailto:linamat@=
telco.md">linamat(a)telco.md</A> <<A href=3D"http://us.mc507.mail.yahoo.co=
m/mc/compose?to=3Dlinamat(a)telco.md" ymailto=3D"mailto:linamat@telco.md">lin=
amat(a)telco.md</A>> wrote:<BR>>><BR>>><BR>>> From: <A h=
ref=3D"http://us.mc507.mail.yahoo.com/mc/compose?to=3Dlinamat@telco.md" yma=
ilto=3D"mailto:linamat@telco.md">linamat(a)telco.md</A> <<A href=3D"http:/=
/us.mc507.mail.yahoo.com/mc/compose?to=3Dlinamat(a)telco.md" ymailto=3D"mailt=
o:linamat@telco.md">linamat(a)telco.md</A>><BR>>> Subject: Re: (ITS#=
6453) OpenLDAP memory leak on LDAP_TIMEOUT<BR>>> To: <A href=3D"http:=
//us.mc507.mail.yahoo.com/mc/compose?to=3Dopenldap-its(a)OpenLDAP.org"
ymailto=3D"mailto:openldap-its@OpenLDAP.org">openldap-its(a)OpenLDAP.org</A>=
<BR>>> Cc: <A href=3D"http://us.mc507.mail.yahoo.com/mc/compose?to=3D=
alinachegalati(a)yahoo.com" ymailto=3D"mailto:alinachegalati@yahoo.com">alina=
chegalati(a)yahoo.com</A><BR>>> Date: Friday, February 12, 2010, 1:34 P=
M<BR>>><BR>>><BR>>> Buna ziua, domnule.<BR>>><BR>&g=
t;> 1. The pointer must be checked before operation, e.g.<BR>>> if=
(res !=3D NULL) {<BR>>> ldap_msgfree (res);<=
BR>>> res =3D NULL;<BR>>> }<BR>>>=
<BR>>> 2. Also while processing the ext query, you should call the fu=
nctions in<BR>> the following manner:<BR>>> 2.1 ldap_search_ext() =
which has pointer to msgid<BR>>> 2.2 ldap_result() which gives the LD=
APMessage structure for the msgid<BR>> 2.3 if ok - ldap_parse_result()<B=
R>>> 2.4 on any stage if something is not good and you have the msgid
filled<BR>> with value (integer, typicaly more then 1) you should call<=
BR>>> ldap_abandon_ext() for that msgid<BR>>> 2.5 Finish with l=
dap_msgfree()<BR>>><BR>>> 3. Periodically between the asynchron=
ous searches (after 100 for<BR>> example)you should call ldap_result() w=
ith short timer and LDAP_RES_ANY<BR>argue for clearing stalled or nonfreed =
calls. The obtained LDAPMessage<BR>can be freed with ldap_msgfree(). Of cou=
rse, you can count the asynch<BR>calls which hadn't been completed or were =
timed out and you can make the<BR>corresponding cycle for checking all iter=
ations.<BR>>><BR>>> Please try and let me know.<BR>>><BR>=
>> With respect, Serghei.<BR>>><BR>>><BR>>><BR>>=
><BR>>><BR>><BR>><BR>><BR>><BR>><BR>><BR><BR><BR=
></DIV></BLOCKQUOTE></td></tr></table><br>=0A=0A
--0-1691785669-1266069835=:3216--
13 years, 3 months
Re: (ITS#6453) OpenLDAP memory leak on LDAP_TIMEOUT
by alinachegalati＠yahoo.com
--0-1809525330-1266055620=:51355
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Sorry, it is my fault here. I missed the trailling "s"...=20
=A0
I am using the OpenLDAP api only for searching for ldap entries on a differ=
ent LDAP serve (I am not aware of its type).=A0 So the only libraries linke=
d to my app are libldap_r.so and liblber.so.
=A0
I don' have access to the source code now=A0but I'll post a section of it s=
oon.
=A0
The idea of using ldap_result with LDAP_RES_ANY is interesting. Do you know=
what is the difference between LDAP_RES_ANY and LDAP_RES_UNSOLICITED? I'm =
thinking to create a separate daemon thread that takes ldap_connections fro=
m the pool and makes this call. My main concern is not to clash with the ex=
isting results.
=A0
I'll try this solution and let you know how it worked.
=A0
Regards,
Alin
=A0
--- On Sat, 2/13/10, linamat(a)telco.md <linamat(a)telco.md> wrote:
From: linamat(a)telco.md <linamat(a)telco.md>
Subject: Re: (ITS#6453) OpenLDAP memory leak on LDAP_TIMEOUT
To: alinachegalati(a)yahoo.com
Date: Saturday, February 13, 2010, 12:52 AM
>
>=A0 =A0 =A0 For the first point, the function ldap_msgfree=A0 will check f=
or
NULL, > so if the check is missing, no error occurs.
>
I believe the pointer should be checked for NULL just to be safe in cases
when implementation suddenly changes.
>=A0 =A0=A0=A0I am using the ldap_search_ext_s function (the synchronous on=
e) so
the >second and third point doesn't apply as i don't have access to
the msgid. >If the memory leak is high maybe will switch to the
async queries.
> Regards,
> Alin
You wrote "We have a memory leak LDAP_TIMEOUT is encountered on
ldap_search_ext_invocation". It not clear if sync or async primitive is
used. If ldap_search_ext_s is used then general timeout set per
LDAPConnection is aplied. May be ldap_search_ext_st is better for use.
As to point 3 it can be applied in your case for checking and destroying
pending or timed out operations.
I am currently using openldap in different applications on Solaris
x86/x64/sparc=A0=A0=A0both 32-bit and 64 without any troubles. Also we need=
to
mention that you can try libldap for version 2.4.16 as it seems to be rock
stable and free of this issues. Also if you are using dbd backend, dbd
must be 4.7.25 + 4 patches recommended by Oracle.
You could post the code block for verifying.
With respect, Serghei.
>
>
>
>
> --- On Fri, 2/12/10, linamat(a)telco.md <linamat(a)telco.md> wrote:
>
>
> From: linamat(a)telco.md <linamat(a)telco.md>
> Subject: Re: (ITS#6453) OpenLDAP memory leak on LDAP_TIMEOUT
> To: openldap-its(a)OpenLDAP.org
> Cc: alinachegalati(a)yahoo.com
> Date: Friday, February 12, 2010, 1:34 PM
>
>
> Buna ziua, domnule.
>
> 1. The pointer must be checked before operation, e.g.
> if (res !=3D NULL) {
>=A0 =A0=A0=A0ldap_msgfree (res);
>=A0 =A0=A0=A0res =3D NULL;
> }
>
> 2. Also while processing the ext query, you should call the functions in
the following manner:
> 2.1 ldap_search_ext() which has pointer to msgid
> 2.2 ldap_result() which gives the LDAPMessage structure for the msgid
2.3 if ok - ldap_parse_result()
> 2.4 on any stage if something is not good and you have the msgid filled
with value (integer, typicaly more then 1) you should call
> ldap_abandon_ext() for that msgid
> 2.5 Finish with ldap_msgfree()
>
> 3. Periodically between the asynchronous searches (after 100 for
example)you should call ldap_result() with short timer and LDAP_RES_ANY
argue for clearing stalled or nonfreed calls. The obtained LDAPMessage
can be freed with ldap_msgfree(). Of course, you can count the asynch
calls which hadn't been completed or were timed out and you can make the
corresponding cycle for checking all iterations.
>
> Please try and let me know.
>
> With respect, Serghei.
>
>
>
>
>
=0A=0A=0A
--0-1809525330-1266055620=:51355
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
<table cellspacing=3D"0" cellpadding=3D"0" border=3D"0" ><tr><td valign=3D"=
top" style=3D"font: inherit;"><DIV><BR>Sorry, it is my fault here. I missed=
the trailling "s"... </DIV>
<DIV> </DIV>
<DIV>I am using the OpenLDAP api only for searching for ldap entries on a d=
ifferent LDAP serve (I am not aware of its type). So the only librari=
es linked to my app are libldap_r.so and liblber.so.</DIV>
<DIV> </DIV>
<DIV>I don' have access to the source code now but I'll post a section=
of it soon.</DIV>
<DIV> </DIV>
<DIV>The idea of using ldap_result with LDAP_RES_ANY is interesting. Do you=
know what is the difference between LDAP_RES_ANY and LDAP_RES_UNSOLICITED?=
I'm thinking to create a separate daemon thread that takes ldap_connection=
s from the pool and makes this call. My main concern is not to clash with t=
he existing results.</DIV>
<DIV> </DIV>
<DIV>I'll try this solution and let you know how it worked.</DIV>
<DIV> </DIV>
<DIV>Regards,</DIV>
<DIV>Alin</DIV>
<DIV> </DIV>
<DIV><BR>--- On <B>Sat, 2/13/10, linamat(a)telco.md <I><linamat(a)telco.md&g=
t;</I></B> wrote:<BR></DIV>
<BLOCKQUOTE style=3D"BORDER-LEFT: rgb(16,16,255) 2px solid; PADDING-LEFT: 5=
px; MARGIN-LEFT: 5px"><BR>From: linamat(a)telco.md <linamat(a)telco.md><B=
R>Subject: Re: (ITS#6453) OpenLDAP memory leak on LDAP_TIMEOUT<BR>To: alina=
chegalati(a)yahoo.com<BR>Date: Saturday, February 13, 2010, 12:52 AM<BR><BR>
<DIV class=3DplainMail>><BR>> For the first point=
, the function ldap_msgfree will check for<BR>NULL, > so if the ch=
eck is missing, no error occurs.<BR>><BR><BR>I believe the pointer shoul=
d be checked for NULL just to be safe in cases<BR>when implementation sudde=
nly changes.<BR><BR>> I am using the ldap_search=
_ext_s function (the synchronous one) so<BR>the >second and third point =
doesn't apply as i don't have access to<BR>the msgid. >If the memory lea=
k is high maybe will switch to the<BR>async queries.<BR>> Regards,<BR>&g=
t; Alin<BR><BR>You wrote "We have a memory leak LDAP_TIMEOUT is encountered=
on<BR>ldap_search_ext_invocation". It not clear if sync or async primitive=
is<BR>used. If ldap_search_ext_s is used then general timeout set per<BR>L=
DAPConnection is aplied. May be ldap_search_ext_st is better for use.<BR><B=
R>As to point 3 it can be applied in your case for checking and
destroying<BR>pending or timed out operations.<BR><BR>I am currently using=
openldap in different applications on Solaris<BR>x86/x64/sparc =
both 32-bit and 64 without any troubles. Also we need to<BR>mention t=
hat you can try libldap for version 2.4.16 as it seems to be rock<BR>stable=
and free of this issues. Also if you are using dbd backend, dbd<BR>must be=
4.7.25 + 4 patches recommended by Oracle.<BR><BR>You could post the code b=
lock for verifying.<BR><BR>With respect, Serghei.<BR><BR>><BR>><BR>&g=
t;<BR>><BR>> --- On Fri, 2/12/10, <A href=3D"http://us.mc507.mail.yah=
oo.com/mc/compose?to=3Dlinamat@telco.md" ymailto=3D"mailto:linamat@telco.md=
">linamat(a)telco.md</A> <<A href=3D"http://us.mc507.mail.yahoo.com/mc/com=
pose?to=3Dlinamat(a)telco.md" ymailto=3D"mailto:linamat@telco.md">linamat@tel=
co.md</A>> wrote:<BR>><BR>><BR>> From: <A href=3D"http://us.mc5=
07.mail.yahoo.com/mc/compose?to=3Dlinamat@telco.md"
ymailto=3D"mailto:linamat@telco.md">linamat(a)telco.md</A> <<A href=3D"ht=
tp://us.mc507.mail.yahoo.com/mc/compose?to=3Dlinamat@telco.md" ymailto=3D"m=
ailto:linamat@telco.md">linamat(a)telco.md</A>><BR>> Subject: Re: (ITS#=
6453) OpenLDAP memory leak on LDAP_TIMEOUT<BR>> To: <A href=3D"http://us=
.mc507.mail.yahoo.com/mc/compose?to=3Dopenldap-its(a)OpenLDAP.org" ymailto=3D=
"mailto:openldap-its@OpenLDAP.org">openldap-its(a)OpenLDAP.org</A><BR>> Cc=
: <A href=3D"http://us.mc507.mail.yahoo.com/mc/compose?to=3Dalinachegalati@=
yahoo.com" ymailto=3D"mailto:alinachegalati@yahoo.com">alinachegalati@yahoo=
.com</A><BR>> Date: Friday, February 12, 2010, 1:34 PM<BR>><BR>><B=
R>> Buna ziua, domnule.<BR>><BR>> 1. The pointer must be checked b=
efore operation, e.g.<BR>> if (res !=3D NULL) {<BR>> &nbs=
p; ldap_msgfree (res);<BR>> res =3D NULL;<B=
R>> }<BR>><BR>> 2. Also while processing the ext query, you should=
call the
functions in<BR>the following manner:<BR>> 2.1 ldap_search_ext() which =
has pointer to msgid<BR>> 2.2 ldap_result() which gives the LDAPMessage =
structure for the msgid<BR>2.3 if ok - ldap_parse_result()<BR>> 2.4 on a=
ny stage if something is not good and you have the msgid filled<BR>with val=
ue (integer, typicaly more then 1) you should call<BR>> ldap_abandon_ext=
() for that msgid<BR>> 2.5 Finish with ldap_msgfree()<BR>><BR>> 3.=
Periodically between the asynchronous searches (after 100 for<BR>example)y=
ou should call ldap_result() with short timer and LDAP_RES_ANY<BR>argue for=
clearing stalled or nonfreed calls. The obtained LDAPMessage<BR>can be fre=
ed with ldap_msgfree(). Of course, you can count the asynch<BR>calls which =
hadn't been completed or were timed out and you can make the<BR>correspondi=
ng cycle for checking all iterations.<BR>><BR>> Please try and let me=
know.<BR>><BR>> With respect,
Serghei.<BR>><BR>><BR>><BR>><BR>><BR><BR><BR></DIV></BLOCKQ=
UOTE></td></tr></table><br>=0A=0A
--0-1809525330-1266055620=:51355--
13 years, 3 months
Re: (ITS#6471) dynlist overlay only acknowledging last dynlist-attrset statement
by quanah＠zimbra.com
--On Saturday, February 13, 2010 2:08 AM +0000 j(a)gropefruit.com wrote:
> Actually, maybe I wasn't totally wrong. There MAY be a bug at work, =
> just not the one I initially thought ....
>
> 1.) Implemented your exact working example on my dev server. Worked.
> 2.) Implemented same example on my QA server. Worked.
> 3.) Implemented on a production server. Failed.
>
> I then realized the dynlist-attrset was listed as follows:
>
> syncrepl params
> accesslog params
> dynlist-attrset params
>
> I then moved the slapd.conf dynlist configuration lines ABOVE syncrepl =
> lines (below my indexes for this DB).
>
> Example then worked in production.
>
> Is THAT a bug? That its behavior changes depending on where it is placed =
> inside of a given 'database' section?
>
> Thanks, sorry to keep bugging you with this ....
Yes, that would be a bug. 2.4 shouldn't be overlay order dependant.
--Quanah
--
Quanah Gibson-Mount
Principal Software Engineer
Zimbra, Inc
--------------------
Zimbra :: the leader in open source messaging and collaboration
13 years, 3 months
Re: (ITS#6471) dynlist overlay only acknowledging last dynlist-attrset statement
by j＠gropefruit.com
Actually, maybe I wasn't totally wrong. There MAY be a bug at work, =
just not the one I initially thought ....
1.) Implemented your exact working example on my dev server. Worked.
2.) Implemented same example on my QA server. Worked.
3.) Implemented on a production server. Failed.
I then realized the dynlist-attrset was listed as follows:
syncrepl params
accesslog params
dynlist-attrset params
I then moved the slapd.conf dynlist configuration lines ABOVE syncrepl =
lines (below my indexes for this DB).
Example then worked in production.
Is THAT a bug? That its behavior changes depending on where it is placed =
inside of a given 'database' section?
Thanks, sorry to keep bugging you with this ....
J=
13 years, 3 months
(ITS#6473) delta-syncrepl "replicates" entries with unknown schema elements
by quanah＠zimbra.com
Full_Name: Quanah Gibson-Mount
Version: 2.3.43
OS: Linux 2.6
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (75.111.45.108)
Recent discrepancies on client replica systems that were 100% reproducible
showed that when using delta-syncrepl, it is easy to get a master/replica out of
sync in the following scenario when using slapd.conf:
A) Stop the master
B) update the master with a schema that adds an additional attribute
C) Start the master
D) Modify an existing entry on the master, setting the new attribute with a
value
The replica will update its database with the event, but ignoring the new
attribute and the value set for it, incorrectly updating its CSN. Instead of
accepting the replication event, it should stop replication until its schema is
updated to match that of the master.
Master log of the modification:
dn: reqStart=20100213000511.000002Z,cn=accesslog
objectClass: auditModify
structuralObjectClass: auditModify
reqStart: 20100213000511.000002Z
reqEnd: 20100213000511.000003Z
reqType: modify
reqSession: 3
reqAuthzID: uid=zimbra,cn=admins,cn=zimbra
reqDN: cn=config,cn=zimbra
reqResult: 0
reqMod: zimbraMailUseDirectBuffers:= FALSE
reqMod: entryCSN:= 20100213000511Z#000000#00#000000
reqMod: modifiersName:= uid=zimbra,cn=admins,cn=zimbra
reqMod: modifyTimestamp:= 20100213000511Z
entryUUID: 328fcc94-ac7f-102e-8753-251cf08bb530
creatorsName: cn=accesslog
createTimestamp: 20100213000511Z
entryCSN: 20100213000511Z#000000#00#000000
modifiersName: cn=accesslog
modifyTimestamp: 20100213000511Z
On the replica, we see:
ber_scanf fmt ({ml{) ber:
ber_dump: buf=0x9f811c0 ptr=0x9f811c3 end=0x9f81375 len=434
0000: 64 82 01 49 04 2c 72 65 71 53 74 61 72 74 3d 32 d..I.,reqStart=2
0010: 30 31 30 30 32 31 33 30 30 30 35 31 31 2e 30 30 0100213000511.00
0020: 30 30 30 32 5a 2c 63 6e 3d 61 63 63 65 73 73 6c 0002Z,cn=accessl
0030: 6f 67 30 82 01 17 30 13 04 07 72 65 71 54 79 70 og0...0...reqTyp
0040: 65 31 08 04 06 6d 6f 64 69 66 79 30 1e 04 05 72 e1...modify0...r
0050: 65 71 44 4e 31 15 04 13 63 6e 3d 63 6f 6e 66 69 eqDN1...cn=confi
0060: 67 2c 63 6e 3d 7a 69 6d 62 72 61 30 81 af 04 06 g,cn=zimbra0....
0070: 72 65 71 4d 6f 64 31 81 a4 04 22 7a 69 6d 62 72 reqMod1..."zimbr
0080: 61 4d 61 69 6c 55 73 65 44 69 72 65 63 74 42 75 aMailUseDirectBu
0090: 66 66 65 72 73 3a 3d 20 46 41 4c 53 45 04 2b 65 ffers:= FALSE.+e
00a0: 6e 74 72 79 43 53 4e 3a 3d 20 32 30 31 30 30 32 ntryCSN:= 201002
00b0: 31 33 30 30 30 35 31 31 5a 23 30 30 30 30 30 30 13000511Z#000000
00c0: 23 30 30 23 30 30 30 30 30 30 04 2e 6d 6f 64 69 #00#000000..modi
00d0: 66 69 65 72 73 4e 61 6d 65 3a 3d 20 75 69 64 3d fiersName:= uid=
00e0: 7a 69 6d 62 72 61 2c 63 6e 3d 61 64 6d 69 6e 73 zimbra,cn=admins
00f0: 2c 63 6e 3d 7a 69 6d 62 72 61 04 21 6d 6f 64 69 ,cn=zimbra.!modi
0100: 66 79 54 69 6d 65 73 74 61 6d 70 3a 3d 20 32 30 fyTimestamp:= 20
0110: 31 30 30 32 31 33 30 30 30 35 31 31 5a 30 2e 04 100213000511Z0..
0120: 08 65 6e 74 72 79 43 53 4e 31 22 04 20 32 30 31 .entryCSN1". 201
0130: 30 30 32 31 33 30 30 30 35 31 31 5a 23 30 30 30 00213000511Z#000
0140: 30 30 30 23 30 30 23 30 30 30 30 30 30 a0 63 30 000#00#000000.c0
0150: 61 04 18 31 2e 33 2e 36 2e 31 2e 34 2e 31 2e 34 a..1.3.6.1.4.1.4
0160: 32 30 33 2e 31 2e 39 2e 31 2e 32 04 45 30 43 0a 203.1.9.1.2.E0C.
0170: 01 01 04 10 32 8f cc 94 ac 7f 10 2e 87 53 25 1c ....2........S%.
0180: f0 8b b5 30 04 2c 63 73 6e 3d 32 30 31 30 30 32 ...0.,csn=201002
0190: 31 33 30 30 30 35 31 31 5a 23 30 30 30 30 30 30 13000511Z#000000
01a0: 23 30 30 23 30 30 30 30 30 30 2c 72 69 64 3d 31 #00#000000,rid=1
01b0: 30 30 00
ldap_get_attribute_ber
ber_scanf fmt ({mM}) ber:
ber_dump: buf=0x9f811c0 ptr=0x9f811f9 end=0x9f81310 len=279
0000: 30 13 04 07 72 65 71 54 79 70 65 31 08 04 06 6d 0...reqType1...m
0010: 6f 64 69 66 79 30 1e 04 05 72 65 71 44 4e 31 15 odify0...reqDN1.
0020: 04 13 63 6e 3d 63 6f 6e 66 69 67 2c 63 6e 3d 7a ..cn=config,cn=z
0030: 69 6d 62 72 61 30 81 af 04 06 72 65 71 4d 6f 64 imbra0....reqMod
0040: 31 81 a4 04 22 7a 69 6d 62 72 61 4d 61 69 6c 55 1..."zimbraMailU
0050: 73 65 44 69 72 65 63 74 42 75 66 66 65 72 73 3a seDirectBuffers:
0060: 3d 20 46 41 4c 53 45 04 2b 65 6e 74 72 79 43 53 = FALSE.+entryCS
0070: 4e 3a 3d 20 32 30 31 30 30 32 31 33 30 30 30 35 N:= 201002130005
0080: 31 31 5a 23 30 30 30 30 30 30 23 30 30 23 30 30 11Z#000000#00#00
0090: 30 30 30 30 04 2e 6d 6f 64 69 66 69 65 72 73 4e 0000..modifiersN
00a0: 61 6d 65 3a 3d 20 75 69 64 3d 7a 69 6d 62 72 61 ame:= uid=zimbra
00b0: 2c 63 6e 3d 61 64 6d 69 6e 73 2c 63 6e 3d 7a 69 ,cn=admins,cn=zi
00c0: 6d 62 72 61 04 21 6d 6f 64 69 66 79 54 69 6d 65 mbra.!modifyTime
00d0: 73 74 61 6d 70 3a 3d 20 32 30 31 30 30 32 31 33 stamp:= 20100213
00e0: 30 30 30 35 31 31 5a 30 2e 04 08 65 6e 74 72 79 000511Z0...entry
00f0: 43 53 4e 31 22 04 20 32 30 31 30 30 32 31 33 30 CSN1". 201002130
0100: 30 30 35 31 31 5a 23 30 30 30 30 30 30 23 30 30 00511Z#000000#00
0110: 23 30 30 30 30 30 30 #000000
ldap_get_attribute_ber
ber_scanf fmt ({mM}) ber:
ber_dump: buf=0x9f811c0 ptr=0x9f8120e end=0x9f81310 len=258
0000: 00 1e 04 05 72 65 71 44 4e 31 15 04 13 63 6e 3d ....reqDN1...cn=
0010: 63 6f 6e 66 69 67 2c 63 6e 3d 7a 69 6d 62 72 61 config,cn=zimbra
0020: 30 81 af 04 06 72 65 71 4d 6f 64 31 81 a4 04 22 0....reqMod1..."
0030: 7a 69 6d 62 72 61 4d 61 69 6c 55 73 65 44 69 72 zimbraMailUseDir
0040: 65 63 74 42 75 66 66 65 72 73 3a 3d 20 46 41 4c ectBuffers:= FAL
0050: 53 45 04 2b 65 6e 74 72 79 43 53 4e 3a 3d 20 32 SE.+entryCSN:= 2
0060: 30 31 30 30 32 31 33 30 30 30 35 31 31 5a 23 30 0100213000511Z#0
0070: 30 30 30 30 30 23 30 30 23 30 30 30 30 30 30 04 00000#00#000000.
0080: 2e 6d 6f 64 69 66 69 65 72 73 4e 61 6d 65 3a 3d .modifiersName:=
0090: 20 75 69 64 3d 7a 69 6d 62 72 61 2c 63 6e 3d 61 uid=zimbra,cn=a
00a0: 64 6d 69 6e 73 2c 63 6e 3d 7a 69 6d 62 72 61 04 dmins,cn=zimbra.
00b0: 21 6d 6f 64 69 66 79 54 69 6d 65 73 74 61 6d 70 !modifyTimestamp
00c0: 3a 3d 20 32 30 31 30 30 32 31 33 30 30 30 35 31 := 2010021300051
00d0: 31 5a 30 2e 04 08 65 6e 74 72 79 43 53 4e 31 22 1Z0...entryCSN1"
00e0: 04 20 32 30 31 30 30 32 31 33 30 30 30 35 31 31 . 20100213000511
00f0: 5a 23 30 30 30 30 30 30 23 30 30 23 30 30 30 30 Z#000000#00#0000
0100: 30 30 00
>>> dnPrettyNormal: <cn=config,cn=zimbra>
=> ldap_bv2dn(cn=config,cn=zimbra,0)
<= ldap_bv2dn(cn=config,cn=zimbra)=0
=> ldap_dn2bv(272)
<= ldap_dn2bv(cn=config,cn=zimbra)=0
=> ldap_dn2bv(272)
<= ldap_dn2bv(cn=config,cn=zimbra)=0
<<< dnPrettyNormal: <cn=config,cn=zimbra>, <cn=config,cn=zimbra>
ldap_get_attribute_ber
ber_scanf fmt ({mM}) ber:
ber_dump: buf=0x9f811c0 ptr=0x9f8122e end=0x9f81310 len=226
0000: 00 81 af 04 06 72 65 71 4d 6f 64 31 81 a4 04 22 .....reqMod1..."
0010: 7a 69 6d 62 72 61 4d 61 69 6c 55 73 65 44 69 72 zimbraMailUseDir
0020: 65 63 74 42 75 66 66 65 72 73 3a 3d 20 46 41 4c ectBuffers:= FAL
0030: 53 45 04 2b 65 6e 74 72 79 43 53 4e 3a 3d 20 32 SE.+entryCSN:= 2
0040: 30 31 30 30 32 31 33 30 30 30 35 31 31 5a 23 30 0100213000511Z#0
0050: 30 30 30 30 30 23 30 30 23 30 30 30 30 30 30 04 00000#00#000000.
0060: 2e 6d 6f 64 69 66 69 65 72 73 4e 61 6d 65 3a 3d .modifiersName:=
0070: 20 75 69 64 3d 7a 69 6d 62 72 61 2c 63 6e 3d 61 uid=zimbra,cn=a
0080: 64 6d 69 6e 73 2c 63 6e 3d 7a 69 6d 62 72 61 04 dmins,cn=zimbra.
0090: 21 6d 6f 64 69 66 79 54 69 6d 65 73 74 61 6d 70 !modifyTimestamp
00a0: 3a 3d 20 32 30 31 30 30 32 31 33 30 30 30 35 31 := 2010021300051
00b0: 31 5a 30 2e 04 08 65 6e 74 72 79 43 53 4e 31 22 1Z0...entryCSN1"
00c0: 04 20 32 30 31 30 30 32 31 33 30 30 30 35 31 31 . 20100213000511
00d0: 5a 23 30 30 30 30 30 30 23 30 30 23 30 30 30 30 Z#000000#00#0000
00e0: 30 30 00
ldap_get_attribute_ber
ber_scanf fmt ({mM}) ber:
ber_dump: buf=0x9f811c0 ptr=0x9f812e0 end=0x9f81310 len=48
0000: 00 2e 04 08 65 6e 74 72 79 43 53 4e 31 22 04 20 ....entryCSN1".
0010: 32 30 31 30 30 32 31 33 30 30 30 35 31 31 5a 23 20100213000511Z#
0020: 30 30 30 30 30 30 23 30 30 23 30 30 30 30 30 30 000000#00#000000
ldap_get_attribute_ber
>>> dnPretty: <uid=zimbra,cn=admins,cn=zimbra>
=> ldap_bv2dn(uid=zimbra,cn=admins,cn=zimbra,0)
<= ldap_bv2dn(uid=zimbra,cn=admins,cn=zimbra)=0
=> ldap_dn2bv(272)
<= ldap_dn2bv(uid=zimbra,cn=admins,cn=zimbra)=0
<<< dnPretty: <uid=zimbra,cn=admins,cn=zimbra>
>>> dnNormalize: <uid=zimbra,cn=admins,cn=zimbra>
=> ldap_bv2dn(uid=zimbra,cn=admins,cn=zimbra,0)
<= ldap_bv2dn(uid=zimbra,cn=admins,cn=zimbra)=0
=> ldap_dn2bv(272)
<= ldap_dn2bv(uid=zimbra,cn=admins,cn=zimbra)=0
<<< dnNormalize: <uid=zimbra,cn=admins,cn=zimbra>
bdb_modify: cn=config,cn=zimbra
bdb_dn2entry("cn=config,cn=zimbra")
bdb_modify_internal: 0x0000000c: cn=config,cn=zimbra
<= acl_access_allowed: granted to database root
bdb_modify_internal: replace entryCSN
bdb_modify_internal: replace modifiersName
bdb_modify_internal: replace modifyTimestamp
=> key_change(DELETE,c)
bdb_idl_delete_key: c
<= key_change 0
=> key_change(ADD,c)
bdb_idl_insert_key: c
<= key_change 0
=> entry_encode(0x0000000c): cn=config,cn=zimbra
bdb_modify: updated id=0000000c dn="cn=config,cn=zimbra"
send_ldap_result: conn=-1 op=0 p=0
send_ldap_result: err=0 matched="" text=""
syncrepl_message_to_op: rid 100 be_modify cn=config,cn=zimbra (0)
bdb_modify:
bdb_dn2entry("")
bdb_modify_internal: 0x00000000:
<= acl_access_allowed: granted to database root
bdb_modify_internal: replace contextCSN
=> entry_encode(0x00000000):
bdb_modify: updated id=00000000 dn=""
send_ldap_result: conn=-1 op=0 p=0
send_ldap_result: err=0 matched="" text=""
ldap_msgfree
As you can see, the replica *clearly* sees the attribute in question, but fails
to throw an error, and simply updates the database with all of the other changes
(entryCSN, etc) then updates the contextCSN.
13 years, 3 months
Re: (ITS#6471) dynlist overlay only acknowledging last dynlist-attrset statement
by j＠gropefruit.com
> Isn't this what you expect?
>=20
That is EXACTLY what I expect. But all hits either come back in POSIX =
format (e.g: just the usernames alone), OR LDAP format (e.g: DNs as =
members). Never BOTH (like in your example, which is what we want).
So, yes, your TEST is correct. However I am seeing something very =
different on my end.
Clearly I am doing something wrong. Either:
1.) A syntax error somewhere in my URI syntax, or
2.) A syntax error somewhere in the dynlist overlay area in my =
slapd.conf
> It represents the objectClass that, when present in an entry that is =
being
> returned by a search, triggers the dynlist expansion.
>=20
That TOO is what I interpreted from both the examples and the manpage.
So you have answered my question:
1.) Is not a bug
2.) What I am trying to do is perfectly valid
3.) I am the problem - I am doing something wrong =3D)
Thank you Pierangelo, as always you're extremely helpful.
J
> p.
>=20
13 years, 3 months
Re: (ITS#6471) dynlist overlay only acknowledging last dynlist-attrset statement
by masarati＠aero.polimi.it
> Pierangelo,=20
>
> Thanks for responding. Here are some hopefully helpful answers:
>
> We have an Openfire (Java-based XMPP server, supporting ldap user/group =
> lookups) server that will, when deployed, have thousands of users. =
> Openfire works quite well with openldap, however we wanted to avoid =
> manually maintaining the group objects since (as I said) they would be =
> highly populated.
>
> Openfire supports two types of groups (in their terms): posix and =
> non-posix. Basically what this means is that when in posix mode, =
> Openfire looks for groups (e.g: cn=3Dusers) that contain UID-like =
> objects (single username strings). When in NON-POSIX mode, however, =
> Openfire will look for groups that contain DN-based members. =20
>
> The member Attribute names (e.g: memberUid, uniqueMember, etc) are fully =
> configurable to openfire, but we had limited success when trying =
> different permutations. Some attribute-mappings work, some do not. =
> Eventually, we found that the following works for Openfire:
>
> overlay dynlist
> dynlist-attrset groupOfURLs memberURL memberUid
>
> With this record being returned when queried:
>
> dn: cn=3Dusers,cn=3Dgroups,dc=3Dexample,dc=3Dcom
> cn: users
> memberURL: =
> ldap:///cn=3Dlogin,cn=3Dauth,dc=3Dexample,dc=3Dcom?uid?one?(objectClass=3D=
> simpleSecurityObject)
> objectClass: groupOfURLs
> memberUid:
> uid=3Dopenfire-admin,cn=3Dlogin,cn=3Dauth,dc=3Dexample,dc=3Dcom=
>
> memberUid: uid=3Duser1,cn=3Dlogin,cn=3Dauth,dc=3Dexample,dc=3Dcom
> memberUid: uid=3Duser2,cn=3Dlogin,cn=3Dauth,dc=3Dexample,dc=3Dcom
> memberUid: uid=3Duser3,cn=3Dlogin,cn=3Dauth,dc=3Dexample,dc=3Dcom
> memberUid: uid=3Duser4,cn=3Dlogin,cn=3Dauth,dc=3Dexample,dc=3Dcom
> memberUid: uid=3Duser5,cn=3Dlogin,cn=3Dauth,dc=3Dexample,dc=3Dcom
> memberUid: uid=3Duser6,cn=3Dlogin,cn=3Dauth,dc=3Dexample,dc=3Dcom
> memberUid: uid=3Duser7,cn=3Dlogin,cn=3Dauth,dc=3Dexample,dc=3Dcom
> memberUid: uid=3Duser8,cn=3Dlogin,cn=3Dauth,dc=3Dexample,dc=3Dcom
> memberUid: uid=3Duser9,cn=3Dlogin,cn=3Dauth,dc=3Dexample,dc=3Dcom
>
> I know this doesn't look right (obviously memberUid is not typically a =
> DN-based value) BUT THIS WORKS FOR OPENFIRE (which in the end, will be =
> the only client that makes use of this record). We'd prefer to use =
> DN-based member groups (e.g: this would be "Non-Posix" groups to =
> openfire) since this is the only method that works with Openfire.
>
> HOWEVER on the other side of the situation, we want to begin using =
> Dynamic Posix Groups, like so:
>
> overlay dynlist
> dynlist-attrset posixGroup memberURL memberUid:uid
>
> With this record being returned when queried:
>
> dn: cn=3Dadmins,cn=3Dposix,cn=3Dgroups,dc=3Dexample,dc=3Dcom
> objectClass: posixGroup
> objectClass: top
> objectClass: extensibleObject
> cn: systems
> gidNumber: 9001
> memberURL: =
> ldap:///cn=3Dplain,cn=3Dauth,dc=3Dexample,dc=3Dcom?uid?one?(objectClass=3D=
> adminUser)
> memberUid: admin1
> memberUid: admin2
> memberUid: admin3
> memberUid: admin4
> memberUid: admin5
>
> .... Which works wonderfully! Using shell commands like 'id' , 'groups' =
> will work quite nicely on the posix/shell level.
>
> But all goes to crap when combining the above dynlist-attrsets. As I =
> said, only one seems to be evaluated.
I'm afraid I don't quite understand.
1) I manually ran test003
2) I configured slapd with
overlay dynlist
dynlist-attrset groupOfURLs memberURL memberUid
dynlist-attrset posixGroup memberURL memberUid:uid
3) I loaded the LDIF
dn: ou=dynlist,dc=example,dc=com
objectClass: organizationalUnit
dn: cn=dl1,ou=dynlist,dc=example,dc=com
objectClass: groupOfURLs
memberURL: ldap:///dc=example,dc=com?uid?sub?(objectClass=person)
dn: cn=dl2,ou=dynlist,dc=example,dc=com
objectClass: posixGroup
objectClass: extensibleObject
memberURL: ldap:///dc=example,dc=com?uid?sub?(objectClass=person)
gidNumber: 0
4) when I execute
$ ldapsearch -x -b ou=dynlist,dc=example,dc=com
I get
# extended LDIF
#
# LDAPv3
# base <ou=dynlist,dc=example,dc=com> with scope subtree
# filter: (objectclass=*)
# requesting: ALL
#
# dynlist, example.com
dn: ou=dynlist,dc=example,dc=com
objectClass: organizationalUnit
ou: dynlist
# dl1, dynlist, example.com
dn: cn=dl1,ou=dynlist,dc=example,dc=com
objectClass: groupOfURLs
memberURL: ldap:///dc=example,dc=com?uid?sub?(objectClass=person)
cn: dl1
memberUid: cn=Barbara Jensen,ou=Information Technology Division,ou=People,
dc=example,dc=com
memberUid: cn=Bjorn Jensen,ou=Information Technology Division,ou=People,dc
=example,dc=com
memberUid: cn=Dorothy Stevens,ou=Alumni Association,ou=People,dc=example,d
c=com
memberUid: cn=James A Jones 1,ou=Alumni Association,ou=People,dc=example,d
c=com
memberUid: cn=James A Jones 2,ou=Information Technology Division,ou=People
,dc=example,dc=com
memberUid: cn=Jane Doe,ou=Alumni Association,ou=People,dc=example,dc=com
memberUid: cn=Jennifer Smith,ou=Alumni Association,ou=People,dc=example,dc
=com
memberUid: cn=John Doe,ou=Information Technology Division,ou=People,dc=exa
mple,dc=com
memberUid: cn=Manager,dc=example,dc=com
memberUid: cn=Mark Elliot,ou=Alumni Association,ou=People,dc=example,dc=co
m
memberUid: cn=Ursula Hampster,ou=Alumni Association,ou=People,dc=example,d
c=com
# dl2, dynlist, example.com
dn: cn=dl2,ou=dynlist,dc=example,dc=com
objectClass: posixGroup
objectClass: extensibleObject
memberURL: ldap:///dc=example,dc=com?uid?sub?(objectClass=person)
gidNumber: 0
cn: dl2
memberUid: bjensen
memberUid: bjorn
memberUid: dots
memberUid: jaj
memberUid: jjones
memberUid: jdoe
memberUid: jen
memberUid: johnd
memberUid: melliot
memberUid: uham
# search result
search: 2
result: 0 Success
# numResponses: 4
# numEntries: 3
Isn't this what you expect?
> I have tried incorporating the =
> optional URI parameter into the dynlist-attrsets, but this totally broke =
> the groups altogether (didn't expand at all).
>
> I guess I don't understand what role the first ObjectClass listed in the =
> dynlist-attrset parameter plays - i assumed it would act appropriately =
> for objects that are using the same OC that is listed in the rule.
It represents the objectClass that, when present in an entry that is being
returned by a search, triggers the dynlist expansion.
p.
13 years, 3 months
Re: (ITS#6453) OpenLDAP memory leak on LDAP_TIMEOUT
by alinachegalati＠yahoo.com
--0-1804724661-1266012508=:41453
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
On point to note, i have the same situation as here : http://www.openldap.o=
rg/lists/openldap-technical/200912/msg00007.html
--- On Fri, 2/12/10, alin vasile <alinachegalati(a)yahoo.com> wrote:
From: alin vasile <alinachegalati(a)yahoo.com>
Subject: Re: (ITS#6453) OpenLDAP memory leak on LDAP_TIMEOUT
To: linamat(a)telco.md
Cc: openldap-its(a)OpenLDAP.org
Date: Friday, February 12, 2010, 1:56 PM
looping openldap group
--- On Fri, 2/12/10, alin vasile <alinachegalati(a)yahoo.com> wrote:
From: alin vasile <alinachegalati(a)yahoo.com>
Subject: Re: (ITS#6453) OpenLDAP memory leak on LDAP_TIMEOUT
To: linamat(a)telco.md
Date: Friday, February 12, 2010, 1:55 PM
Hi Serghei,
=A0
=A0=A0=A0=A0 For the first point, the function ldap_msgfree=A0 will check f=
or NULL, so if the check is missing, no error occurs.
=A0
=A0=A0=A0 I am using the ldap_search_ext_s function (the synchronous one) s=
o the second and third point doesn't apply as i don't have access to the ms=
gid. If the memory leak is high maybe will switch to the async queries.
=A0
Regards,
Alin
=A0
=A0=A0=20
=A0=A0=A0=20
--- On Fri, 2/12/10, linamat(a)telco.md <linamat(a)telco.md> wrote:
From: linamat(a)telco.md <linamat(a)telco.md>
Subject: Re: (ITS#6453) OpenLDAP memory leak on LDAP_TIMEOUT
To: openldap-its(a)OpenLDAP.org
Cc: alinachegalati(a)yahoo.com
Date: Friday, February 12, 2010, 1:34 PM
Buna ziua, domnule.
1. The pointer must be checked before operation, e.g.
if (res !=3D NULL) {
=A0 =A0 ldap_msgfree (res);
=A0 =A0 res =3D NULL;
}
2. Also while processing the ext query, you should call the functions in
the following manner:
2.1 ldap_search_ext() which has pointer to msgid
2.2 ldap_result() which gives the LDAPMessage structure for the msgid
2.3 if ok - ldap_parse_result()
2.4 on any stage if something is not good and you have the msgid filled
with value (integer, typicaly more then 1) you should call
ldap_abandon_ext() for that msgid
2.5 Finish with ldap_msgfree()
3. Periodically between the asynchronous searches (after 100 for
example)you should call ldap_result() with short timer and LDAP_RES_ANY
argue for clearing stalled or nonfreed calls. The obtained LDAPMessage can
be freed with ldap_msgfree(). Of course, you can count the asynch calls
which hadn't been completed or were timed out and you can make the
corresponding cycle for checking all iterations.
Please try and let me know.
With respect, Serghei.
=0A=0A=0A
--0-1804724661-1266012508=:41453
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
<table cellspacing=3D"0" cellpadding=3D"0" border=3D"0" ><tr><td valign=3D"=
top" style=3D"font: inherit;">On point to note, i have the same situation a=
s here : <A href=3D"http://www.openldap.org/lists/openldap-technical/200912=
/msg00007.html">http://www.openldap.org/lists/openldap-technical/200912/msg=
00007.html</A><BR><BR>--- On <B>Fri, 2/12/10, alin vasile <I><alinachega=
lati(a)yahoo.com></I></B> wrote:<BR>
<BLOCKQUOTE style=3D"BORDER-LEFT: rgb(16,16,255) 2px solid; PADDING-LEFT: 5=
px; MARGIN-LEFT: 5px"><BR>From: alin vasile <alinachegalati(a)yahoo.com>=
;<BR>Subject: Re: (ITS#6453) OpenLDAP memory leak on LDAP_TIMEOUT<BR>To: li=
namat(a)telco.md<BR>Cc: openldap-its(a)OpenLDAP.org<BR>Date: Friday, February 1=
2, 2010, 1:56 PM<BR><BR>
<DIV id=3Dyiv1659718545>
<TABLE border=3D0 cellSpacing=3D0 cellPadding=3D0>
<TBODY>
<TR>
<TD vAlign=3Dtop>looping openldap group<BR><BR>--- On <B>Fri, 2/12/10, alin=
vasile <I><alinachegalati(a)yahoo.com></I></B> wrote:<BR>
<BLOCKQUOTE style=3D"BORDER-LEFT: rgb(16,16,255) 2px solid; PADDING-LEFT: 5=
px; MARGIN-LEFT: 5px"><BR>From: alin vasile <alinachegalati(a)yahoo.com>=
;<BR>Subject: Re: (ITS#6453) OpenLDAP memory leak on LDAP_TIMEOUT<BR>To: li=
namat(a)telco.md<BR>Date: Friday, February 12, 2010, 1:55 PM<BR><BR>
<DIV id=3Dyiv1668921465>
<TABLE border=3D0 cellSpacing=3D0 cellPadding=3D0>
<TBODY>
<TR>
<TD vAlign=3Dtop>
<DIV>Hi Serghei,</DIV>
<DIV> </DIV>
<DIV> For the first point, the function ldap_msgfre=
e will check for NULL, so if the check is missing, no error occurs.</=
DIV>
<DIV> </DIV>
<DIV> I am using the ldap_search_ext_s function (the sync=
hronous one) so the second and third point doesn't apply as i don't have ac=
cess to the msgid. If the memory leak is high maybe will switch to the asyn=
c queries.</DIV>
<DIV> </DIV>
<DIV>Regards,</DIV>
<DIV>Alin</DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV> <BR><BR>--- On <B>Fri, 2/12/10, linamat(a)telco.md <I=
><linamat(a)telco.md></I></B> wrote:<BR></DIV>
<BLOCKQUOTE style=3D"BORDER-LEFT: rgb(16,16,255) 2px solid; PADDING-LEFT: 5=
px; MARGIN-LEFT: 5px"><BR>From: linamat(a)telco.md <linamat(a)telco.md><B=
R>Subject: Re: (ITS#6453) OpenLDAP memory leak on LDAP_TIMEOUT<BR>To: openl=
dap-its(a)OpenLDAP.org<BR>Cc: alinachegalati(a)yahoo.com<BR>Date: Friday, Febru=
ary 12, 2010, 1:34 PM<BR><BR>
<DIV class=3DplainMail>Buna ziua, domnule.<BR><BR>1. The pointer must be ch=
ecked before operation, e.g.<BR>if (res !=3D NULL) {<BR> ldap_=
msgfree (res);<BR> res =3D NULL;<BR>}<BR><BR>2. Also while pro=
cessing the ext query, you should call the functions in<BR>the following ma=
nner:<BR>2.1 ldap_search_ext() which has pointer to msgid<BR>2.2 ldap_resul=
t() which gives the LDAPMessage structure for the msgid<BR>2.3 if ok - ldap=
_parse_result()<BR>2.4 on any stage if something is not good and you have t=
he msgid filled<BR>with value (integer, typicaly more then 1) you should ca=
ll<BR>ldap_abandon_ext() for that msgid<BR>2.5 Finish with ldap_msgfree()<B=
R><BR>3. Periodically between the asynchronous searches (after 100 for<BR>e=
xample)you should call ldap_result() with short timer and LDAP_RES_ANY<BR>a=
rgue for clearing stalled or nonfreed calls. The obtained LDAPMessage can<B=
R>be freed with ldap_msgfree(). Of course, you can count the asynch
calls<BR>which hadn't been completed or were timed out and you can make th=
e<BR>corresponding cycle for checking all iterations.<BR><BR>Please try and=
let me know.<BR><BR>With respect, Serghei.<BR><BR></DIV></BLOCKQUOTE></TD>=
</TR></TBODY></TABLE><BR></DIV></BLOCKQUOTE></TD></TR></TBODY></TABLE><BR><=
/DIV></BLOCKQUOTE></td></tr></table><br>=0A=0A=0A=0A
--0-1804724661-1266012508=:41453--
13 years, 3 months
Re: (ITS#6453) OpenLDAP memory leak on LDAP_TIMEOUT
by alinachegalati＠yahoo.com
--0-1659389023-1266011766=:33437
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
looping openldap group
--- On Fri, 2/12/10, alin vasile <alinachegalati(a)yahoo.com> wrote:
From: alin vasile <alinachegalati(a)yahoo.com>
Subject: Re: (ITS#6453) OpenLDAP memory leak on LDAP_TIMEOUT
To: linamat(a)telco.md
Date: Friday, February 12, 2010, 1:55 PM
Hi Serghei,
=A0
=A0=A0=A0=A0 For the first point, the function ldap_msgfree=A0 will check f=
or NULL, so if the check is missing, no error occurs.
=A0
=A0=A0=A0 I am using the ldap_search_ext_s function (the synchronous one) s=
o the second and third point doesn't apply as i don't have access to the ms=
gid. If the memory leak is high maybe will switch to the async queries.
=A0
Regards,
Alin
=A0
=A0=A0=20
=A0=A0=A0=20
--- On Fri, 2/12/10, linamat(a)telco.md <linamat(a)telco.md> wrote:
From: linamat(a)telco.md <linamat(a)telco.md>
Subject: Re: (ITS#6453) OpenLDAP memory leak on LDAP_TIMEOUT
To: openldap-its(a)OpenLDAP.org
Cc: alinachegalati(a)yahoo.com
Date: Friday, February 12, 2010, 1:34 PM
Buna ziua, domnule.
1. The pointer must be checked before operation, e.g.
if (res !=3D NULL) {
=A0 =A0 ldap_msgfree (res);
=A0 =A0 res =3D NULL;
}
2. Also while processing the ext query, you should call the functions in
the following manner:
2.1 ldap_search_ext() which has pointer to msgid
2.2 ldap_result() which gives the LDAPMessage structure for the msgid
2.3 if ok - ldap_parse_result()
2.4 on any stage if something is not good and you have the msgid filled
with value (integer, typicaly more then 1) you should call
ldap_abandon_ext() for that msgid
2.5 Finish with ldap_msgfree()
3. Periodically between the asynchronous searches (after 100 for
example)you should call ldap_result() with short timer and LDAP_RES_ANY
argue for clearing stalled or nonfreed calls. The obtained LDAPMessage can
be freed with ldap_msgfree(). Of course, you can count the asynch calls
which hadn't been completed or were timed out and you can make the
corresponding cycle for checking all iterations.
Please try and let me know.
With respect, Serghei.
=0A=0A=0A
--0-1659389023-1266011766=:33437
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
<table cellspacing=3D"0" cellpadding=3D"0" border=3D"0" ><tr><td valign=3D"=
top" style=3D"font: inherit;">looping openldap group<BR><BR>--- On <B>Fri, =
2/12/10, alin vasile <I><alinachegalati(a)yahoo.com></I></B> wrote:<BR>
<BLOCKQUOTE style=3D"BORDER-LEFT: rgb(16,16,255) 2px solid; PADDING-LEFT: 5=
px; MARGIN-LEFT: 5px"><BR>From: alin vasile <alinachegalati(a)yahoo.com>=
;<BR>Subject: Re: (ITS#6453) OpenLDAP memory leak on LDAP_TIMEOUT<BR>To: li=
namat(a)telco.md<BR>Date: Friday, February 12, 2010, 1:55 PM<BR><BR>
<DIV id=3Dyiv1668921465>
<TABLE border=3D0 cellSpacing=3D0 cellPadding=3D0>
<TBODY>
<TR>
<TD vAlign=3Dtop>
<DIV>Hi Serghei,</DIV>
<DIV> </DIV>
<DIV> For the first point, the function ldap_msgfre=
e will check for NULL, so if the check is missing, no error occurs.</=
DIV>
<DIV> </DIV>
<DIV> I am using the ldap_search_ext_s function (the sync=
hronous one) so the second and third point doesn't apply as i don't have ac=
cess to the msgid. If the memory leak is high maybe will switch to the asyn=
c queries.</DIV>
<DIV> </DIV>
<DIV>Regards,</DIV>
<DIV>Alin</DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV> <BR><BR>--- On <B>Fri, 2/12/10, linamat(a)telco.md <I=
><linamat(a)telco.md></I></B> wrote:<BR></DIV>
<BLOCKQUOTE style=3D"BORDER-LEFT: rgb(16,16,255) 2px solid; PADDING-LEFT: 5=
px; MARGIN-LEFT: 5px"><BR>From: linamat(a)telco.md <linamat(a)telco.md><B=
R>Subject: Re: (ITS#6453) OpenLDAP memory leak on LDAP_TIMEOUT<BR>To: openl=
dap-its(a)OpenLDAP.org<BR>Cc: alinachegalati(a)yahoo.com<BR>Date: Friday, Febru=
ary 12, 2010, 1:34 PM<BR><BR>
<DIV class=3DplainMail>Buna ziua, domnule.<BR><BR>1. The pointer must be ch=
ecked before operation, e.g.<BR>if (res !=3D NULL) {<BR> ldap_=
msgfree (res);<BR> res =3D NULL;<BR>}<BR><BR>2. Also while pro=
cessing the ext query, you should call the functions in<BR>the following ma=
nner:<BR>2.1 ldap_search_ext() which has pointer to msgid<BR>2.2 ldap_resul=
t() which gives the LDAPMessage structure for the msgid<BR>2.3 if ok - ldap=
_parse_result()<BR>2.4 on any stage if something is not good and you have t=
he msgid filled<BR>with value (integer, typicaly more then 1) you should ca=
ll<BR>ldap_abandon_ext() for that msgid<BR>2.5 Finish with ldap_msgfree()<B=
R><BR>3. Periodically between the asynchronous searches (after 100 for<BR>e=
xample)you should call ldap_result() with short timer and LDAP_RES_ANY<BR>a=
rgue for clearing stalled or nonfreed calls. The obtained LDAPMessage can<B=
R>be freed with ldap_msgfree(). Of course, you can count the asynch
calls<BR>which hadn't been completed or were timed out and you can make th=
e<BR>corresponding cycle for checking all iterations.<BR><BR>Please try and=
let me know.<BR><BR>With respect, Serghei.<BR><BR></DIV></BLOCKQUOTE></TD>=
</TR></TBODY></TABLE><BR></DIV></BLOCKQUOTE></td></tr></table><br>=0A=0A =
--0-1659389023-1266011766=:33437--
13 years, 3 months