openldap-bugs

openldap-bugs@openldap.org

1 participants
20959 discussions

Re: (ITS#6471) dynlist overlay only acknowledging last dynlist-attrset statement
by masarati＠aero.polimi.it 14 Feb '10

14 Feb '10

> Interesting. I can't seem to imagine why this behaved the way it did = > (looking over my config again) I am just happy that moving it fixed = > the issue. Well, unless you can come up with a configuration AND a test case that is fully reproducible, I'd rather avoid spending further time on this issue. If the problem is related to intermixing configuration statements, then it is a bug, but it might only surface when something really odd happens (like one module mucking with some pointer somewhere and not restoring things as they should be). Then the only thing we can do is exactly track what caused this. However, in your case, you're not actually intermixing statements, but rather sort overlays differently: all dynlist related statements exactly follow the "overlay dynlist" statement, but different overlays are ordered differently. This calls for unexpected interaction between overlays stack execution that results in the odd behavior you observed. This should be a bug as well, unless there is a good reason for having different behavior when overlays are stacked differently (e.g. an overlay legally mucks with data that is later handled by another). Again, unless you can present a clearly reproducible case, it's quite hard to track, and likely impossible if it's data dependent. So I'm happy you solved your specific issue by rearranging the order of the overlays. p.

1 0

Re: (ITS#6471) dynlist overlay only acknowledging last dynlist-attrset statement
by j＠gropefruit.com 14 Feb '10

14 Feb '10

Interesting. I can't seem to imagine why this behaved the way it did = (looking over my config again) I am just happy that moving it fixed = the issue. On Feb 14, 2010, at 00:55 , masarati(a)aero.polimi.it wrote: >> First of all, I am paraphrasing. No one is hiding anything from you = =3D >> Pierre. You need only ask.=3D20 >>=20 >>> It is supposed to be a bug. It's also the reason I asked from the >>> beginning to see the real configuration, real data and real = operation >>> causing the issue. If you keep hiding essential details, and only =3D= >> provide >>> bits of information each time, it'll take ages to just discover = where =3D >> the >>> issue is. >>=20 >>=20 >>> So now the only way to keep this ITS open is to see your ENTIRE =3D >> slapd.conf >>> (except passwords, of course). An even better alternative would be = to >>> receive a sanitized slapd.conf, a LDIF and a search operation based = on >>> ldapsearch that clearly illustrates the issue, like what I posted a = =3D >> couple >>> of postings ago. >>=20 >> Here, the entire sanitized config. I left out the ACL file (the = include =3D >> statement at the very end), but the behavior in question was = happening =3D >> to the rootdn user as well, meaning ACLs weren't the culprit. I also = =3D >> removed 14 of 15 of the syncrepl stanzas for brevity, as they were = all =3D >> the same aside from hostname/IP. >>=20 >> NOTE the sections labeled WORKS HERE, and BROKEN HERE, which denote = the =3D >> original (dysfunctional) position vs the current (functional) = position. >=20 > I can't see any difference in behavior with the configuration in > <ftp://ftp.openldap.org/incoming/slapd-its6471-1.conf>, the data and = the > ldapsearch command described in my previous posting (the only = difference > is that now, after "./run -b hdb test003" you need to manually create > directory "testrun/db.2.a" for the log database, and bind as the = rootdn to > perform the search). I tried both HEAD and current re24 code, which > should not differ much from 2.4.21. The only modifications to > configuration are related to: statically built backends/overlays, no = ACLs, > no TLS. Also, valgrind does not show anything strange (like dangling > pointers or so) which could be symptoms of doing nasty things with = memory > that make my setup work "by chance". >=20 > p. >=20

1 0

Re: (ITS#6471) dynlist overlay only acknowledging last dynlist-attrset statement
by masarati＠aero.polimi.it 14 Feb '10

14 Feb '10

> First of all, I am paraphrasing. No one is hiding anything from you = > Pierre. You need only ask.=20 > >> It is supposed to be a bug. It's also the reason I asked from the >> beginning to see the real configuration, real data and real operation >> causing the issue. If you keep hiding essential details, and only = > provide >> bits of information each time, it'll take ages to just discover where = > the >> issue is. > > >> So now the only way to keep this ITS open is to see your ENTIRE = > slapd.conf >> (except passwords, of course). An even better alternative would be to >> receive a sanitized slapd.conf, a LDIF and a search operation based on >> ldapsearch that clearly illustrates the issue, like what I posted a = > couple >> of postings ago. > > Here, the entire sanitized config. I left out the ACL file (the include = > statement at the very end), but the behavior in question was happening = > to the rootdn user as well, meaning ACLs weren't the culprit. I also = > removed 14 of 15 of the syncrepl stanzas for brevity, as they were all = > the same aside from hostname/IP. > > NOTE the sections labeled WORKS HERE, and BROKEN HERE, which denote the = > original (dysfunctional) position vs the current (functional) position. I can't see any difference in behavior with the configuration in <ftp://ftp.openldap.org/incoming/slapd-its6471-1.conf>, the data and the ldapsearch command described in my previous posting (the only difference is that now, after "./run -b hdb test003" you need to manually create directory "testrun/db.2.a" for the log database, and bind as the rootdn to perform the search). I tried both HEAD and current re24 code, which should not differ much from 2.4.21. The only modifications to configuration are related to: statically built backends/overlays, no ACLs, no TLS. Also, valgrind does not show anything strange (like dangling pointers or so) which could be symptoms of doing nasty things with memory that make my setup work "by chance". p.

1 0

Re: (ITS#6471) dynlist overlay only acknowledging last dynlist-attrset statement
by j＠gropefruit.com 13 Feb '10

13 Feb '10

First of all, I am paraphrasing. No one is hiding anything from you = Pierre. You need only ask.=20 > It is supposed to be a bug. It's also the reason I asked from the > beginning to see the real configuration, real data and real operation > causing the issue. If you keep hiding essential details, and only = provide > bits of information each time, it'll take ages to just discover where = the > issue is. > So now the only way to keep this ITS open is to see your ENTIRE = slapd.conf > (except passwords, of course). An even better alternative would be to > receive a sanitized slapd.conf, a LDIF and a search operation based on > ldapsearch that clearly illustrates the issue, like what I posted a = couple > of postings ago. Here, the entire sanitized config. I left out the ACL file (the include = statement at the very end), but the behavior in question was happening = to the rootdn user as well, meaning ACLs weren't the culprit. I also = removed 14 of 15 of the syncrepl stanzas for brevity, as they were all = the same aside from hostname/IP. NOTE the sections labeled WORKS HERE, and BROKEN HERE, which denote the = original (dysfunctional) position vs the current (functional) position. ###### include /etc/ldap/schema/core.schema include /etc/ldap/schema/cosine.schema include /etc/ldap/schema/nis.schema include /etc/ldap/schema/inetorgperson.schema include /etc/ldap/schema/misc.schema include /etc/ldap/schema/openldap.schema include /etc/ldap/schema/duaconf.schema include /etc/ldap/schema/dyngroup.schema include /etc/ldap/schema/ppolicy.schema include /etc/ldap/schema/sudo.schema include /etc/ldap/schema/dhcp.schema include /etc/ldap/schema/samba.schema include /usr/share/doc/libpam-ldap/ldapns.schema include /etc/ldap/schema/hdb.schema include /etc/ldap/schema/uber.schema include /etc/ldap/schema/nisdomainobject.schema pidfile /var/run/slapd/slapd.pid argsfile /var/run/slapd/slapd.args tool-threads 4 loglevel stats stats2 sync ## Modules/Overlays modulepath /usr/lib/ldap moduleload back_hdb moduleload back_monitor.la moduleload syncprov moduleload accesslog moduleload dynlist.la serverID 100 ldap://10.94.100.100:3890/ TLSCertificateFile /etc/ldap/ssl/wildcard.example.com.crt TLSCertificateKeyFile /etc/ldap/ssl/wildcard.example.com.key TLSCACertificateFile /etc/ssl/certs/ca-example.cert TLSVerifyClient never ## Limits, Mandates & Allowances disallow bind_anon sizelimit unlimited timelimit unlimited security tls=3D0 access to dn.subtree=3D"cn=3DSubschema" by users read access to dn.base=3D"" by users read defaultSearchBase dc=3Dexample,dc=3Dcom sasl-realm EXAMPLE.COM sasl-host ds.example.com authz-regexp "uid=3D$.*$,cn=3DEXAMPLE.COM,cn=3Dgssapi,cn=3Dauth" "uid=3D$1,cn=3Dplain,cn=3Dauth,dc=3Dexample,dc=3Dcom" backend hdb ########### Monitoring Database - For slapd/hdb performance data database monitor rootdn uid=3Dmonitor,cn=3Dmonitor rootpw {SSHA}.... access to dn.subtree=3D"cn=3Dmonitor" by = group/groupOfUniqueNames/uniqueMember=3D"cn=3Dldapadmin,cn=3Dldap,cn=3Dgro= ups,dc=3Dexample,dc=3Dcom" read ########### Example Log database hdb suffix cn=3Dexamplelog rootdn "uid=3Dlog,cn=3Dexamplelog" rootpw {SSHA}.... directory /var/lib/ldap/examplelog index reqStart,objectClass,entryCSN,reqResult eq dbconfig set_cachesize 0 4097152 0 dbconfig set_lg_regionmax 1048576 dbconfig set_lg_max 1048576 dbconfig set_lg_dir /var/lib/ldap/examplelog dbconfig set_tmp_dir /tmp overlay syncprov syncprov-nopresent TRUE syncprov-reloadhint TRUE access to dn.subtree=3D"cn=3Dexamplelog" by = group/groupOfUniqueNames/uniqueMember=3D"cn=3Dldapadmin,cn=3Dldap,cn=3Dgro= ups,dc=3Dexample,dc=3Dcom" read ########### Example.Com database hdb idlcachesize 4000 suffix "dc=3Dexample,dc=3Dcom" checksum checkpoint 10 1 cachefree 20 rootdn "uid=3Drootdn,cn=3Dplain,cn=3Dauth,dc=3Dexample,dc= =3Dcom" rootpw {SSHA}.... monitoring on lastmod on directory "/var/lib/ldap/example" dncachesize 1000 dbconfig set_cachesize 1 0 2 dbconfig set_lg_max 10485760 dbconfig set_lg_regionmax 40485760 dbconfig set_flags db_log_autoremove dbconfig set_lg_bsize 20971520 dbconfig set_lk_max_objects 5500 dbconfig set_lk_max_locks 5500 dbconfig set_lk_max_lockers 5500 index objectClass eq =20 index entryCSN,entryUUID eq =20 index cn,uid,memberUid eq index uidNumber,gidNumber eq ############### ### WORKS HERE overlay dynlist dynlist-attrset groupOfURLs memberURL memberUid dynlist-attrset posixGroup memberURL memberUid:uid ## There were 15 of these, removed 14 for brevity. syncrepl rid=3D001 provider=3Dldap://10.94.100.100:3890/ starttls=3Dyes bindmethod=3Dsimple binddn=3D"uid=3Dsyncrepl,cn=3Dplain,cn=3Dauth,dc=3Dexample,dc=3Dcom" credentials=3Dpassword scope=3Dsub filter=3D"(objectClass=3D*)" schemachecking=3Doff searchbase=3D"dc=3Dexample,dc=3Dcom" attrs=3D"*,+" retry=3D"12 +" sizelimit=3Dunlimited timeout=3D20 type=3DrefreshAndPersist mirrormode true overlay syncprov syncprov-sessionlog 10 syncprov-checkpoint 1 5 overlay accesslog logdb cn=3Dexamplelog logops writes logold (objectclass=3D*) logpurge 7+00:00 2+00:00 logsuccess TRUE ################## ### IS BROKEN HERE overlay dynlist dynlist-attrset groupOfURLs memberURL memberUid dynlist-attrset posixGroup memberURL memberUid:uid include /etc/ldap/acls

1 0

Re: (ITS#6471) dynlist overlay only acknowledging last dynlist-attrset statement
by masarati＠aero.polimi.it 13 Feb '10

13 Feb '10

> 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 .... GUESSING what you meant above is something like this (as you keep writing things like "accesslog parameters" instead of the real thing) <slapd.conf excerpt> database bdb suffix "dc=example,dc=com" rootdn "cn=Manager,dc=example,dc=com" rootpw secret #null#bind on directory testrun/db.1.a index objectClass eq index cn,sn,uid pres,eq,sub overlay dynlist dynlist-attrset groupOfURLs memberURL memberUid overlay syncprov overlay accesslog logdb cn=log logops writes reads logold (objectclass=person) dynlist-attrset posixGroup memberURL memberUid:uid </slapd.conf excerpt> or any permutation of the dynlist-attrset statement, like both before overlay syncprov, or both at the end, or anywhere between "overlay syncrepl" and the last "log*" statement, I get the expected result. So now the only way to keep this ITS open is to see your ENTIRE slapd.conf (except passwords, of course). An even better alternative would be to receive a sanitized slapd.conf, a LDIF and a search operation based on ldapsearch that clearly illustrates the issue, like what I posted a couple of postings ago. p.

1 0

Re: (ITS#6471) dynlist overlay only acknowledging last dynlist-attrset statement
by masarati＠aero.polimi.it 13 Feb '10

13 Feb '10

1 0

Re: (ITS#6453) OpenLDAP memory leak on LDAP_TIMEOUT
by alinachegalati＠yahoo.com 13 Feb '10

13 Feb '10

--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&nbsp= ; 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--

1 0

Re: (ITS#6453) OpenLDAP memory leak on LDAP_TIMEOUT
by alinachegalati＠yahoo.com 13 Feb '10

13 Feb '10

--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--

1 0

Re: (ITS#6471) dynlist overlay only acknowledging last dynlist-attrset statement
by j＠gropefruit.com 13 Feb '10

13 Feb '10

Excellent. It's good to know I wasn't totally crazy. Likely to be fixed in 2.4.22 ? Thanks J

1 0

Re: (ITS#6471) dynlist overlay only acknowledging last dynlist-attrset statement
by quanah＠zimbra.com 13 Feb '10

13 Feb '10

--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

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