- openldap-bugs - openldap.org

(ITS#4790) re23 hangs during shutdown after test033
by ando＠sys-net.it 24 Dec '06

24 Dec '06

Full_Name: Pierangelo Masarati Version: re23 (2.3.31) OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (87.28.220.33) Apparently, one thread is unable to terminate correctly, so the test succeeds, but then slapd hangs forever in ldap_pvt_thread_pool_destroy(). I couldn't investigate this in depth right now, but I could easily reproduce it on two different systems (different kernels and so), so I'm positive I can easily reproduce it. p.

1 0

Re: (ITS#4789) can't add BDB database when monitoring
by ando＠sys-net.it 24 Dec '06

24 Dec '06

hyc(a)symas.com wrote: > hyc(a)OpenLDAP.org wrote: > > >> I presume there's some kind of callback for registering new suffixes but I >> haven't looked very hard. >> > > This highlights some other issues lurking in here - back-monitor > basically doesn't deal with dynamic configuration well at all. It > assumes that all databases and overlays have been fully configured by > the time it starts - an assumption that was valid for old-style > slapd.conf use, but not with back-config. > > The monitor_subsys_database_init_one() function probably needs to be > split into separate pieces so that database and overlay info can be set > up and removed incrementally. > The point is that back-monitor has no clean means to detect what database is serving what naming context, since it was designed way ahead of back-config. So when time came to introduce monitor customization, the best mechanism I could find was the extended filter on the naming context. This is really creating trouble. The best solution would be to re-design back-monitor so that the database section mimics back-config using X-ORDERED 'SIBLING' style (and is updated accordingly, especially when entry renaming will be supported by back-config). The X-ORDERED 'SIBLING' could be used throughout back-monitor, to get rid of those "cn=Database X", "cn=Overlay Y" stuff and so. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.n.c. Via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ------------------------------------------ Office: +39.02.23998309 Mobile: +39.333.4963172 Email: pierangelo.masarati(a)sys-net.it ------------------------------------------

1 0

ITS#3707 filters
by hyc＠symas.com 23 Dec '06

23 Dec '06

I've had a patch for the Filter handling sitting here half-finished for quite a while. The intent is to preserve all of the original filter data so that it can be reused directly. On a related note, RFC4511 changes the behavior of presence matching on unknown attributes to be Undefined now instead of FALSE. So presumably we should update our code accordingly. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/

1 0

Re: (ITS#4789) can't add BDB database when monitoring
by hyc＠symas.com 23 Dec '06

23 Dec '06

hyc(a)OpenLDAP.org wrote: > I presume there's some kind of callback for registering new suffixes but I > haven't looked very hard. This highlights some other issues lurking in here - back-monitor basically doesn't deal with dynamic configuration well at all. It assumes that all databases and overlays have been fully configured by the time it starts - an assumption that was valid for old-style slapd.conf use, but not with back-config. The monitor_subsys_database_init_one() function probably needs to be split into separate pieces so that database and overlay info can be set up and removed incrementally. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/

1 0

(ITS#4789) can't add BDB database when monitoring
by hyc＠OpenLDAP.org 23 Dec '06

23 Dec '06

Full_Name: Howard Chu Version: HEAD OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (76.168.84.21) Submitted by: hyc When back-monitor is active, attempting to add a bdb database thru cn=config fails in bdb_monitor_db_open. The call to mbe->register_entry_attrs() fails because the new database's suffixes aren't known to back-monitor: monitor_back_register_entry_attrs(""): base="cn=databases,cn=monitor" scope=one filter="(namingContexts:distinguishedNameMatch:=dc=foo,dc=example,dc=com)": unable to find entry ====> bdb_cache_release_all backend_startup_one: bi_db_open failed! (-1) olcSuffix: value #0: <olcSuffix> failed startup (dc=foo,dc=example,dc=com)! send_ldap_result: conn=0 op=12 p=3 send_ldap_result: err=80 matched="" text="<olcSuffix> failed startup" I presume there's some kind of callback for registering new suffixes but I haven't looked very hard.

1 0

Re: (ITS#4780) ACL set memory leak
by dhawes＠vt.edu 22 Dec '06

22 Dec '06

On Wednesday 20 December 2006 01:43, dhawes(a)vt.edu wrote: > On Tuesday 19 December 2006 23:42, hyc(a)symas.com wrote: > > David Hawes wrote: > > > Here's the valgrind output with the set clause in place: > > > > > > http://filebox.vt.edu/users/dhawes/valgrind-with-set.log > > > > > > Here's the valgrind output without the set clause (for reference): > > > > > > http://filebox.vt.edu/users/dhawes/valgrind-without-set.log > > > > > > The following patch causes memory use to stabilize with my SLAMD test: > > > > Try the patch in HEAD sets.c 1.29 -> 1.30. > > I haven't tested the patch with valgrind yet, but I no longer see the > memory leak with my SLAMD test. Just to follow up, I no longer see the memory leaks with valgrind. dave

1 0

Re: (ITS#4788) test043-delta-syncrepl failed (exit 49)
by hyc＠symas.com 22 Dec '06

22 Dec '06

michael(a)stroeder.com wrote: > Full_Name: Michael Ströder > Version: HEAD > OS: SuSE Linux 10.1 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (83.124.24.222) > > >>>>>> Starting test043-delta-syncrepl ... > running defines.sh > Starting master slapd on TCP/IP port 9011... > Using ldapsearch to check that master slapd is running... > Using ldapadd to create the context prefix entries in the master... > Starting slave slapd on TCP/IP port 9012... > Using ldapsearch to check that slave slapd is running... > Using ldapadd to populate the master directory... > Waiting 15 seconds for syncrepl to receive changes... > Stopping the provider, sleeping 10 seconds and restarting it... > Using ldapsearch to check that master slapd is running... > Using ldapmodify to modify master directory... > Waiting 15 seconds for syncrepl to receive changes... > Stopping consumer to test recovery... > Modifying more entries on the master... > Restarting consumer... > Waiting 25 seconds for syncrepl to receive changes... > Try updating the slave slapd... > ldapmodify failed (49)! >>>>>> ./scripts/test043-delta-syncrepl failed (exit 49) > make[2]: *** [bdb-mod] Error 49 > make[2]: Leaving directory `/home/michael/src/openldap-HEAD/ldap/tests' > make[1]: *** [test] Error 2 > make[1]: Leaving directory `/home/michael/src/openldap-HEAD/ldap/tests' > make: *** [test] Error 2 You didn't look back far enough in slapd.2.log; the real error is here: syncrepl_message_to_entry: rid 001 mods check (auditContext: attribute type undefined) ldap_msgfree this is from Ando's recent patch to accesslog.c. I think that an appropriate fix would be to exclude dsaOperational attributes from replication since they only have meaning on the hosting DSA. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/

1 0

(ITS#4788) test043-delta-syncrepl failed (exit 49)
by michael＠stroeder.com 22 Dec '06

22 Dec '06

Full_Name: Michael Ströder Version: HEAD OS: SuSE Linux 10.1 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (83.124.24.222) >>>>> Starting test043-delta-syncrepl ... running defines.sh Starting master slapd on TCP/IP port 9011... Using ldapsearch to check that master slapd is running... Using ldapadd to create the context prefix entries in the master... Starting slave slapd on TCP/IP port 9012... Using ldapsearch to check that slave slapd is running... Using ldapadd to populate the master directory... Waiting 15 seconds for syncrepl to receive changes... Stopping the provider, sleeping 10 seconds and restarting it... Using ldapsearch to check that master slapd is running... Using ldapmodify to modify master directory... Waiting 15 seconds for syncrepl to receive changes... Stopping consumer to test recovery... Modifying more entries on the master... Restarting consumer... Waiting 25 seconds for syncrepl to receive changes... Try updating the slave slapd... ldapmodify failed (49)! >>>>> ./scripts/test043-delta-syncrepl failed (exit 49) make[2]: *** [bdb-mod] Error 49 make[2]: Leaving directory `/home/michael/src/openldap-HEAD/ldap/tests' make[1]: *** [test] Error 2 make[1]: Leaving directory `/home/michael/src/openldap-HEAD/ldap/tests' make: *** [test] Error 2 ---------------------------------------------------------------------------- test.out: ldap_initialize( ldap://localhost:9012 ) ldap_bind: Invalid credentials (49) ---------------------------------------------------------------------------- last lines of slapd.2.log slap_listener_activate(7): >>> slap_listener(ldap://localhost:9012/)ldap_pvt_gethostbyname_a: host=nb2, r=0 conn=0 fd=11 ACCEPT from IP=127.0.0.1:6312 (IP=127.0.0.1:9012) connection_get(11) connection_get(11): got connid=0 connection_read(11): checking for input on id=0 ber_get_next ber_get_next: tag 0x30 len 46 contents: ber_get_next ber_get_next on fd 11 failed errno=11 (Resource temporarily unavailable) do_bind ber_scanf fmt ({imt) ber: ber_scanf fmt (m}) ber: >>> dnPrettyNormal: <cn=Manager,dc=example,dc=com> => ldap_bv2dn(cn=Manager,dc=example,dc=com,0) <= ldap_bv2dn(cn=Manager,dc=example,dc=com)=0 => ldap_dn2bv(272) <= ldap_dn2bv(cn=Manager,dc=example,dc=com)=0 => ldap_dn2bv(272) <= ldap_dn2bv(cn=manager,dc=example,dc=com)=0 <<< dnPrettyNormal: <cn=Manager,dc=example,dc=com>, <cn=manager,dc=example,dc=com> do_bind: version=3 dn="cn=Manager,dc=example,dc=com" method=128 conn=0 op=0 BIND dn="cn=Manager,dc=example,dc=com" method=128 ==> bdb_bind: dn: cn=Manager,dc=example,dc=com bdb_dn2entry("cn=manager,dc=example,dc=com") => bdb_dn2id("dc=example,dc=com") <= bdb_dn2id: get failed: DB_NOTFOUND: No matching key/data pair found (-30989) send_ldap_result: conn=0 op=0 p=3 send_ldap_result: err=49 matched="" text="" send_ldap_response: msgid=1 tag=97 err=49 ber_flush2: 14 bytes to sd 11 conn=0 op=0 RESULT tag=97 err=49 text= connection_get(11) connection_get(11): got connid=0 connection_read(11): checking for input on id=0 ber_get_next ber_get_next on fd 11 failed errno=0 (Success) connection_closing: readying conn=0 sd=11 for close connection_close: conn=0 sd=11 conn=0 fd=11 closed (connection lost) daemon: shutdown requested and initiated. slapd shutdown: waiting for 0 threads to terminate lt-slapd shutdown: initiated ====> bdb_cache_release_all lt-slapd destroy: freeing system resources.

1 0

Re: (ITS#4783) ldap_sasl_bind() is not asynchronous
by ando＠sys-net.it 22 Dec '06

22 Dec '06

fcusack(a)fcusack.com wrote: > But still you can do the bind async, and just close the fd on the client > side on timeout. I don't see why connect() timeout can't be handled > the same way. (ignoring the problem that there is no API call AFAICT > to just drop the connection) > I'll note that there's been some interest in that area --- I loosely have the same need (see <http://www.openldap.org/lists/openldap-devel/200611/msg00000.html>) but unfortunately it's not in my priority list, considering that it might have relevant impact on the client library. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.n.c. Via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ------------------------------------------ Office: +39.02.23998309 Mobile: +39.333.4963172 Email: pierangelo.masarati(a)sys-net.it ------------------------------------------

1 0

Re: (ITS#4784) a small patch for back-sql
by ando＠sys-net.it 21 Dec '06

21 Dec '06

> back-sql fails to compile with BACKSQL_TRACE defined, I think this is the > correct fix. (blind) fixed in HEAD/re23. Thanks for reporting. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.n.c. Via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ------------------------------------------ Office: +39.02.23998309 Mobile: +39.333.4963172 Email: pierangelo.masarati(a)sys-net.it ------------------------------------------

1 0

(ITS#4787) Download links with version vs. date
by michael＠stroeder.com 21 Dec '06

21 Dec '06

Full_Name: Michael Ströder Version: not relevant OS: not relevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (83.124.17.77) HI! It's hard for beginners to understand the download links here: http://www.openldap.org/software/download/ The file names of latest release contains the release number but the file names of releases tagged as "stable" contains the release date. Current example: 2.3.31 ftp://ftp.openldap.org/pub/OpenLDAP/openldap-release/openldap-2.3.31.tgz 2.3.27 (20060823) ftp://ftp.openldap.org/pub/OpenLDAP/openldap-stable/openldap-stable-2006082… I see several problems with this current practice: 1. Common practice in other open source projects is to create file names with dates only for CVS/SVN snapshots. So it might be hard for beginners to recognize that these files are really stable releases even though the string "stable" is also in the file name. Note that these .tar.gz files could be obtained from another source, not directly from the official download page. 2. On the mailing lists always the version number is referred/proposed. But this does not appear in the file name. And frankly no-one remembers the release dates. Especially since also CHANGES does not contain the release dates. So the only mapping is the download page. 3. Common practice is that the root directory name within the .tar.gz matches the exact version in the .tar.gz file name. => I'd recommend to always create the same form of file names containing solely the release version. I see no benefit in using the date at all. Ciao, Michael.

1 0

Re: (ITS#4786) back-sql searching with dn attribute selected causes object class violation
by robb＠wtg.cw.com 21 Dec '06

21 Dec '06

Pierangelo Masarati wrote: > I'll note that unless you defined it yourself, "dn" is not a valid > attribute name. I suspect your back-sql meta-data generates an entry > that doesn't pass schema checking, otherwise I don't see a chance for > that error to be reported. Pierangelo, the objects are inetOrgPerson objects, the full object looks like this # robb(a)example.org, sql.example.org dn: uid=robb(a)example.org,dc=sql,dc=example,dc=org objectClass: inetOrgPerson cn: Robert Brooks uid: robb(a)example.org mail: robb(a)example.org I believe the only required attribute for such an object is cn. A similar search against a non back-sql part for the tree (see below) does not show an error ldapsearch -x -b "ou=people,dc=example,dc=org" "cn=Robert Brooks" dn cn objectclass # robb, people, example.org dn: uid=robb,ou=people,dc=example,dc=org cn: Robert Brooks objectClass: account objectClass: posixAccount objectClass: shadowAccount Unfortunately seems some software doesn't understand it doesn't need to request dn explicitly hence I noticed this. > In any case, since the behavior you report is very data and meta-data > dependent, you don't provide enough info for debugging, and at a very > first glance this is not indicative of a software bug. Let me know what you'd like, I thought this one may well reproduce on any back-sql, so didn't spray the ITS with extraneous information. Regards, Rob -- Robert Brooks, Network Manager, Cable & Wireless UK <robb(a)wtg.cw.com> http://wtg.cw.com/ Tel: +44 (0)20 7339 8600 Fax: +44 (0)20 7339 8601 - "What was your username again?" - BOFH -

1 0

Re: (ITS#4786) back-sql searching with dn attribute selected causes object class violation
by ando＠sys-net.it 20 Dec '06

20 Dec '06

robb(a)wtg.cw.com wrote: > an ldapsearch like this works > > ldapsearch -x -b "dc=sql,dc=example,dc=org" "cn=Robert Brooks" cn > > dn: uid=robb(a)example.org,dc=sql,dc=example,dc=org > cn: Robert Brooks > > # search result > search: 2 > result: 0 Success > > # numResponses: 2 > # numEntries: 1 > > however this does not: > > ldapsearch -x -b "dc=sql,dc=example,dc=org" "cn=Robert Brooks" dn cn > > # search result > search: 2 > result: 65 Object class violation > > # numResponses: I'll note that unless you defined it yourself, "dn" is not a valid attribute name. I suspect your back-sql meta-data generates an entry that doesn't pass schema checking, otherwise I don't see a chance for that error to be reported. In any case, since the behavior you report is very data and meta-data dependent, you don't provide enough info for debugging, and at a very first glance this is not indicative of a software bug. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.n.c. Via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ------------------------------------------ Office: +39.02.23998309 Mobile: +39.333.4963172 Email: pierangelo.masarati(a)sys-net.it ------------------------------------------

1 0

Re: (ITS#4783) ldap_sasl_bind() is not asynchronous
by Kurt＠OpenLDAP.org 20 Dec '06

20 Dec '06

At 01:51 PM 12/20/2006, fcusack(a)fcusack.com wrote: >But still you can do the bind async, and just close the fd on the client >side on timeout. If you are waiting on a timeout, you're not truely async. Truely async implies never blocking, including not blocking for a time. > I don't see why connect() timeout can't be handled >the same way. (ignoring the problem that there is no API call AFAICT >to just drop the connection) My comments were for truely async. -- Kurt

1 0

Re: (ITS#4783) ldap_sasl_bind() is not asynchronous
by fcusack＠fcusack.com 20 Dec '06

20 Dec '06

On December 20, 2006 9:18:18 AM +0100 Pierangelo Masarati <ando(a)sys-net.it> wrote: > fcusack(a)fcusack.com wrote: >> On December 19, 2006 7:04:15 PM -0800 "Kurt D. Zeilenga" >> <Kurt(a)OpenLDAP.org> wrote: >> >>> At 05:32 PM 12/19/2006, fcusack(a)fcusack.com wrote: >>> >>>> Full_Name: Frank Cusack >>>> Version: 2.3.27 >>>> OS: any >>>> URL: ftp://ftp.openldap.org/incoming/ >>>> Submission from: (NULL) (209.76.127.62) >>>> >>>> connect() is always done synchronously. Any idea when this will be >>>> fixed? >>>> >>> It's actually not considered a bug. ldap_sasl_bind(3) is async >>> in doesn't wait for the LDAP response. There is no LDAP restart >>> API, as would be needed if the API didn't block on various >>> system calls. >>> >> >> Why is that required here? >> >> ldap_sasl_bind() >> ldap_result() >> if (timeout) { >> ldap_abandon() >> if (just_return_on_error) { >> return error >> } else { >> do_something_else >> } >> } >> >> To restart a bind, just abandon and bind again. >> > There was a discussion recently on the subject (look in hte ITS). A bind > cannot be abandoned as per RFC 4511-19; you need to ldap_unbind_ext and > recreate a fresh connection. OK, I see that abandon isn't really the right thing here. But still you can do the bind async, and just close the fd on the client side on timeout. I don't see why connect() timeout can't be handled the same way. (ignoring the problem that there is no API call AFAICT to just drop the connection) -frank

1 0

(ITS#4786) back-sql searching with dn attribute selected causes object class violation
by robb＠wtg.cw.com 20 Dec '06

20 Dec '06

Full_Name: Robert Brooks Version: 2.3.31 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (62.49.19.14) an ldapsearch like this works ldapsearch -x -b "dc=sql,dc=example,dc=org" "cn=Robert Brooks" cn dn: uid=robb(a)example.org,dc=sql,dc=example,dc=org cn: Robert Brooks # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1 however this does not: ldapsearch -x -b "dc=sql,dc=example,dc=org" "cn=Robert Brooks" dn cn # search result search: 2 result: 65 Object class violation # numResponses:

1 0

(ITS#4785) back-sql objectclass searches fail unless there is data in ldap_entry_objclasses
by robb＠wtg.cw.com 20 Dec '06

20 Dec '06

Full_Name: Robert Brooks Version: 2.3.31 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (62.49.19.14) objectclass searches fail (with back-sql/mysql) if there is no data in the ldap_entry_objclasses table. Just a simple dummy entry like this is enough to fix the problem. +----------+----------+ | entry_id | oc_name | +----------+----------+ | 0 | dcObject | +----------+----------+

1 0

(ITS#4784) a small patch for back-sql
by robb＠wtg.cw.com 20 Dec '06

20 Dec '06

Full_Name: Robert Brooks Version: 2.3.31 OS: Linux URL: ftp://ftp.openldap.org/incoming/openldap-2.3.30-tracesql.patch Submission from: (NULL) (62.49.19.14) back-sql fails to compile with BACKSQL_TRACE defined, I think this is the correct fix.

1 0

Re: (ITS#4783) ldap_sasl_bind() is not asynchronous
by ando＠sys-net.it 20 Dec '06

20 Dec '06

fcusack(a)fcusack.com wrote: > On December 19, 2006 7:04:15 PM -0800 "Kurt D. Zeilenga" > <Kurt(a)OpenLDAP.org> wrote: > >> At 05:32 PM 12/19/2006, fcusack(a)fcusack.com wrote: >> >>> Full_Name: Frank Cusack >>> Version: 2.3.27 >>> OS: any >>> URL: ftp://ftp.openldap.org/incoming/ >>> Submission from: (NULL) (209.76.127.62) >>> >>> connect() is always done synchronously. Any idea when this will be >>> fixed? >>> >> It's actually not considered a bug. ldap_sasl_bind(3) is async >> in doesn't wait for the LDAP response. There is no LDAP restart >> API, as would be needed if the API didn't block on various >> system calls. >> > > Why is that required here? > > ldap_sasl_bind() > ldap_result() > if (timeout) { > ldap_abandon() > if (just_return_on_error) { > return error > } else { > do_something_else > } > } > > To restart a bind, just abandon and bind again. > There was a discussion recently on the subject (look in hte ITS). A bind cannot be abandoned as per RFC 4511-19; you need to ldap_unbind_ext and recreate a fresh connection. > I am not all that familiar with the LDAP API, so forgive me if I'm > way off base here. > p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.n.c. Via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ------------------------------------------ Office: +39.02.23998309 Mobile: +39.333.4963172 Email: pierangelo.masarati(a)sys-net.it ------------------------------------------

1 0

Re: (ITS#4780) ACL set memory leak
by dhawes＠vt.edu 19 Dec '06

19 Dec '06

On Tuesday 19 December 2006 23:42, hyc(a)symas.com wrote: > David Hawes wrote: > > Here's the valgrind output with the set clause in place: > > > > http://filebox.vt.edu/users/dhawes/valgrind-with-set.log > > > > Here's the valgrind output without the set clause (for reference): > > > > http://filebox.vt.edu/users/dhawes/valgrind-without-set.log > > > > The following patch causes memory use to stabilize with my SLAMD test: > > Try the patch in HEAD sets.c 1.29 -> 1.30. I haven't tested the patch with valgrind yet, but I no longer see the memory leak with my SLAMD test. Thanks for your help with this. dave

1 0

ITS#3971 slapo-glue and slapo-rwm
by hyc＠symas.com 19 Dec '06

19 Dec '06

This issue has been fixed in HEAD with the patches for ITS#4638. This ITS will be closed in favor of #4638. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/

1 0

Re: (ITS#4780) ACL set memory leak
by hyc＠symas.com 19 Dec '06

19 Dec '06

David Hawes wrote: > Here's the valgrind output with the set clause in place: > > http://filebox.vt.edu/users/dhawes/valgrind-with-set.log > > Here's the valgrind output without the set clause (for reference): > > http://filebox.vt.edu/users/dhawes/valgrind-without-set.log > > The following patch causes memory use to stabilize with my SLAMD test: Try the patch in HEAD sets.c 1.29 -> 1.30. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/

1 0

Re: (ITS#4783) ldap_sasl_bind() is not asynchronous
by fcusack＠fcusack.com 19 Dec '06

19 Dec '06

On December 19, 2006 7:04:15 PM -0800 "Kurt D. Zeilenga" <Kurt(a)OpenLDAP.org> wrote: > At 05:32 PM 12/19/2006, fcusack(a)fcusack.com wrote: >> Full_Name: Frank Cusack >> Version: 2.3.27 >> OS: any >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (209.76.127.62) >> >> connect() is always done synchronously. Any idea when this will be >> fixed? > > It's actually not considered a bug. ldap_sasl_bind(3) is async > in doesn't wait for the LDAP response. There is no LDAP restart > API, as would be needed if the API didn't block on various > system calls. Why is that required here? ldap_sasl_bind() ldap_result() if (timeout) { ldap_abandon() if (just_return_on_error) { return error } else { do_something_else } } To restart a bind, just abandon and bind again. I am not all that familiar with the LDAP API, so forgive me if I'm way off base here. -frank

1 0

Re: (ITS#4780) ACL set memory leak
by dhawes＠vt.edu 19 Dec '06

19 Dec '06

On Tuesday 19 December 2006 19:39, hyc(a)symas.com wrote: > dhawes(a)vt.edu wrote: > > On Saturday 16 December 2006 08:54, ando(a)sys-net.it wrote: > >> dhawes(a)vt.edu wrote: > >>> I notice the same behavior on 2.3.27, but did not notice it with older > >>> versions such as 2.2.26. > >> > >> I can't confirm this issue neither with HEAD nor with re23; I used > >> valgrind and the set string you posted verbatim, although I didn't use > >> slamd. However, right now I don't see how it may be a matter of > >> concurrency. > > > > I notice the same behavior with 2.3.31 as well. From my testing 2.2.30 > > does not exhibit this behavior while 2.3.4 (and later) does. > > I've also been unable to reproduce this. Can you run using valgrind or > some other malloc tracer and get some diagnostics? Absolutely. Here's the valgrind output with the set clause in place: http://filebox.vt.edu/users/dhawes/valgrind-with-set.log Here's the valgrind output without the set clause (for reference): http://filebox.vt.edu/users/dhawes/valgrind-without-set.log The following patch causes memory use to stabilize with my SLAMD test: --- openldap-2.3.31-orig/servers/slapd/sets.c 2006-01-03 17:16:15.000000000 -0500 +++ openldap-2.3.31/servers/slapd/sets.c 2006-12-19 21:37:40.000000000 -0500 @@ -440,6 +440,7 @@ AC_MEMCPY( set->bv_val, &filter[ - len - 1 ], len ); set->bv_len = len; SF_PUSH( set ); + cp->set_op->o_tmpfree( set->bv_val, cp->set_op->o_tmpmemctx ); set = NULL; break; Of course, this patch makes sets useless, so it's hardly a fix. I'm still looking at the code to determine what's going on here--I'm sure you guys will be able to pinpoint it in an instant. dave

1 0

Re: (ITS#4783) ldap_sasl_bind() is not asynchronous
by Kurt＠OpenLDAP.org 19 Dec '06

19 Dec '06

At 05:32 PM 12/19/2006, fcusack(a)fcusack.com wrote: >Full_Name: Frank Cusack >Version: 2.3.27 >OS: any >URL: ftp://ftp.openldap.org/incoming/ >Submission from: (NULL) (209.76.127.62) > >connect() is always done synchronously. Any idea when this will be fixed? It's actually not considered a bug. ldap_sasl_bind(3) is async in doesn't wait for the LDAP response. There is no LDAP restart API, as would be needed if the API didn't block on various system calls. So the first step in "fixing" this would be to design an LDAP restart API... yet another reason to redesign the whole API... Kurt

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs