--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@telco.md linamat@telco.md wrote:
From: linamat@telco.md linamat@telco.md Subject: Re: (ITS#6453) OpenLDAP memory leak on LDAP_TIMEOUT To: alinachegalati@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@telco.md linamat@telco.md wrote:
From: linamat@telco.md linamat@telco.md Subject: Re: (ITS#6453) OpenLDAP memory leak on LDAP_TIMEOUT To: openldap-its@OpenLDAP.org Cc: alinachegalati@yahoo.com Date: Friday, February 12, 2010, 1:34 PM
Buna ziua, domnule.
- 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; }
- 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()
- 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@telco.md <I><linamat@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@telco.md <linamat@telco.md><B= R>Subject: Re: (ITS#6453) OpenLDAP memory leak on LDAP_TIMEOUT<BR>To: alina= chegalati@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@telco.md</A> <<A href=3D"http://us.mc507.mail.yahoo.com/mc/com= pose?to=3Dlinamat@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@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@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@OpenLDAP.org" ymailto=3D= "mailto:openldap-its@OpenLDAP.org">openldap-its@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--
-
alinachegalatiļ¼ yahoo.com