openldap-bugs

openldap-bugs@openldap.org

1 participants
20963 discussions

Re: (ITS#5827) Syncprov persistent operations info leaking
by hyc＠symas.com 23 Nov '08

23 Nov '08

Pierangelo Masarati wrote: > hyc(a)symas.com wrote: >> ando(a)sys-net.it wrote: >>> Full_Name: Pierangelo Masarati >>> Version: >>> OS: >>> URL: ftp://ftp.openldap.org/incoming/ >>> Submission from: (NULL) (81.72.89.40) >>> Submitted by: ando >>> >>> >>> After heavily loading a MMR pool, valgrind finds the following: >>> >>> ==29650== 2,437 (240 direct, 2,197 indirect) bytes in 3 blocks are definitely >>> lo >>> st in loss record 13 of 15 >> Most likely because we increment s_inuse at line 1250, at the beginning of a >> non-Delete write op, and don't decrement it at the end of the op. I think this >> should be simple to fix, will take a look. > > Seems to work. Thanks, p. I don't think the current fix is complete. Due to the Abandon check at 1190, it's possible (though extremely unlikely) for an Abandon to arrive between the start and end of a mod op, and cause the final decrement to be skipped still. Probably need to do some restructuring to catch this, I'll look at this some more. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#5827) Syncprov persistent operations info leaking
by ando＠sys-net.it 23 Nov '08

23 Nov '08

hyc(a)symas.com wrote: > ando(a)sys-net.it wrote: >> Full_Name: Pierangelo Masarati >> Version: >> OS: >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (81.72.89.40) >> Submitted by: ando >> >> >> After heavily loading a MMR pool, valgrind finds the following: >> >> ==29650== 2,437 (240 direct, 2,197 indirect) bytes in 3 blocks are definitely >> lo >> st in loss record 13 of 15 > > Most likely because we increment s_inuse at line 1250, at the beginning of a > non-Delete write op, and don't decrement it at the end of the op. I think this > should be simple to fix, will take a look. Seems to work. Thanks, p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5827) Syncprov persistent operations info leaking
by hyc＠symas.com 23 Nov '08

23 Nov '08

ando(a)sys-net.it wrote: > Full_Name: Pierangelo Masarati > Version: > OS: > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (81.72.89.40) > Submitted by: ando > > > After heavily loading a MMR pool, valgrind finds the following: > > ==29650== 2,437 (240 direct, 2,197 indirect) bytes in 3 blocks are definitely > lo > st in loss record 13 of 15 Most likely because we increment s_inuse at line 1250, at the beginning of a non-Delete write op, and don't decrement it at the end of the op. I think this should be simple to fix, will take a look. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#5827) Syncprov persistent operations info leaking
by ando＠sys-net.it 23 Nov '08

23 Nov '08

Full_Name: Pierangelo Masarati Version: OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (81.72.89.40) Submitted by: ando After heavily loading a MMR pool, valgrind finds the following: ==29650== 2,437 (240 direct, 2,197 indirect) bytes in 3 blocks are definitely lo st in loss record 13 of 15 ==29650== at 0x40053C0: malloc (vg_replace_malloc.c:149) ==29650== by 0x825903B: ber_memalloc_x (memory.c:226) ==29650== by 0x80A743C: ch_malloc (ch_malloc.c:54) ==29650== by 0x82029CA: syncprov_op_search (syncprov.c:2200) ==29650== by 0x8104F7B: overlay_op_walk (backover.c:660) ==29650== by 0x81051B0: over_op_func (backover.c:722) ==29650== by 0x8105234: over_op_search (backover.c:744) ==29650== by 0x80897F6: fe_op_search (search.c:366) ==29650== by 0x8089196: do_search (search.c:217) ==29650== by 0x8085F41: connection_operation (connection.c:1090) ==29650== by 0x808641B: connection_read_thread (connection.c:1216) ==29650== by 0x8222E9C: ldap_int_thread_pool_wrapper (tpool.c:663) ==29650== by 0xDEB46A: start_thread (in /lib/libpthread-2.5.so) ==29650== by 0xD42DBD: clone (in /lib/libc-2.5.so) ==29594== 2,913 (160 direct, 2,753 indirect) bytes in 2 blocks are definitely lo st in loss record 10 of 15 ==29594== at 0x40053C0: malloc (vg_replace_malloc.c:149) ==29594== by 0x825903B: ber_memalloc_x (memory.c:226) ==29594== by 0x80A743C: ch_malloc (ch_malloc.c:54) ==29594== by 0x82029CA: syncprov_op_search (syncprov.c:2200) ==29594== by 0x8104F7B: overlay_op_walk (backover.c:660) ==29594== by 0x81051B0: over_op_func (backover.c:722) ==29594== by 0x8105234: over_op_search (backover.c:744) ==29594== by 0x80897F6: fe_op_search (search.c:366) ==29594== by 0x8089196: do_search (search.c:217) ==29594== by 0x8085F41: connection_operation (connection.c:1090) ==29594== by 0x808641B: connection_read_thread (connection.c:1216) ==29594== by 0x8222E9C: ldap_int_thread_pool_wrapper (tpool.c:663) ==29594== by 0xDEB46A: start_thread (in /lib/libpthread-2.5.so) ==29594== by 0xD42DBD: clone (in /lib/libc-2.5.so) p.

1 0

Re: (ITS#5825) syncrepl default is no retry
by ando＠sys-net.it 23 Nov '08

23 Nov '08

hyc(a)symas.com wrote: > ando(a)sys-net.it wrote: >> Full_Name: Pierangelo Masarati >> Version: irrelevant >> OS: irrelevant >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (82.63.140.131) >> Submitted by: ando >> >> >> Syncrepl by default uses no retry. This is extremely useless, as syncrepl with >> no retry will probably break, sooner or later, without notifying why it >> happened. > > Legacy behavior, since retry was added later... > >> I believe it would be safe to have either: >> >> - a "safe" retry value (not too often, e.g. every hour, forever) > > Sounds fine, just add it to the doc. > >> - a warning (or an error) if retry is not given when configuring syncrepl > > Sounds rather annoying. We could combine these: if no retry was configured, > give the warning and use a default of 1 hour. Have to ensure that the default > setting doesn't persist in cn=config, so that it will keep warning until an > explicit value is set. > >> Another interesting feature would be to register syncrepl-specific parameters in >> back-monitor's entry of each database, that > >> - show the status of syncrepl (whether it's up, if rp) >> >> - show the timestamp of the last successful refresh >> >> - show the timestamp of the last failed attempt, and the reason of the failure > > Sounds fine, but unless you can add these quickly I don't see any reason to > hold 2.4.13 for it. Didn't mean to :) By now, only the warning is being issued. I don't think I can implement the rest for 2.4.13, will need to wait for next release. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5823) clients/tools don't honor ldap.conf defaults
by ghenry＠OpenLDAP.org 22 Nov '08

22 Nov '08

----- hyc(a)symas.com wrote: > h.b.furuseth(a)usit.uio.no wrote: > > Pierangelo Masarati writes: > >> -ZZ should be deprecated, and -Z should simply and strictly > require > >> StartTLS. > > > > Good point. Except then people who are used to new clients will > > make insecure connections when using old clients. Maybe -Z should > > be an error instead... > > > > What I'd really really like to do is throw away all the options, > > rename the programs, and start over. This time with the same > option > > names in ldap tools, slap tools, and slapd itself. Goes with the > > someday-in-the-future library rewrite, I suppose. > > OpenLDAP 3.0... > > The question is, when do we stop the 2.x stream and begin 3.0? Cool. I say we rewrite it all in Java, this C stuff is hard to understand ;-) -- Kind Regards, Gavin Henry. OpenLDAP Engineering Team. E ghenry(a)OpenLDAP.org Community developed LDAP software. http://www.openldap.org/project/

1 0

Re: (ITS#5825) syncrepl default is no retry
by hyc＠symas.com 22 Nov '08

22 Nov '08

ando(a)sys-net.it wrote: > Full_Name: Pierangelo Masarati > Version: irrelevant > OS: irrelevant > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (82.63.140.131) > Submitted by: ando > > > Syncrepl by default uses no retry. This is extremely useless, as syncrepl with > no retry will probably break, sooner or later, without notifying why it > happened. Legacy behavior, since retry was added later... > I believe it would be safe to have either: > > - a "safe" retry value (not too often, e.g. every hour, forever) Sounds fine, just add it to the doc. > - a warning (or an error) if retry is not given when configuring syncrepl Sounds rather annoying. We could combine these: if no retry was configured, give the warning and use a default of 1 hour. Have to ensure that the default setting doesn't persist in cn=config, so that it will keep warning until an explicit value is set. > Another interesting feature would be to register syncrepl-specific parameters in > back-monitor's entry of each database, that > - show the status of syncrepl (whether it's up, if rp) > > - show the timestamp of the last successful refresh > > - show the timestamp of the last failed attempt, and the reason of the failure Sounds fine, but unless you can add these quickly I don't see any reason to hold 2.4.13 for it. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#5826) syncrepl leaking filter in MMR
by ando＠sys-net.it 22 Nov '08

22 Nov '08

Full_Name: Pierangelo Masarati Version: HEAD/re24 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (82.63.140.131) Submitted by: ando The filterstring is not freed if generated. A fix is coming. p.

1 0

(ITS#5825) syncrepl default is no retry
by ando＠sys-net.it 22 Nov '08

22 Nov '08

Full_Name: Pierangelo Masarati Version: irrelevant OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (82.63.140.131) Submitted by: ando Syncrepl by default uses no retry. This is extremely useless, as syncrepl with no retry will probably break, sooner or later, without notifying why it happened. I believe it would be safe to have either: - a "safe" retry value (not too often, e.g. every hour, forever) - a warning (or an error) if retry is not given when configuring syncrepl Another interesting feature would be to register syncrepl-specific parameters in back-monitor's entry of each database, that - show the status of syncrepl (whether it's up, if rp) - show the timestamp of the last successful refresh - show the timestamp of the last failed attempt, and the reason of the failure p.

1 0

ldap_domain2hostlist is for "ldap" service only
by Marc Lavergne 22 Nov '08

22 Nov '08

Have there been any considerations in providing a similar API for a service name other than "ldap"? For example, what if I wanted to find global catalog servers? Even though GCs are Active Directory specific, I don't see why OpenLDAP would not support that type of query. It seems like a new API where the service name can be passed in as a parameter (eg. "gc") would be useful. Before using ITS to issue a bug report, I thought I'd ask via this forum. Thanks.

4 4

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