openldap-bugs

openldap-bugs@openldap.org

1 participants
20963 discussions

Re: (ITS#5048) Suspicious use of 'unchecked' limit syncprov
by h.b.furuseth＠usit.uio.no 13 Jan '11

13 Jan '11

BTW, why do CSN times have 6-decimal precision when we only care about 1/256 second? Or doesn't it matter if this test is gives false positives for small time differences? -- Hallvard

1 0

Re: (ITS#5048) Suspicious use of 'unchecked' limit syncprov
by h.b.furuseth＠usit.uio.no 13 Jan '11

13 Jan '11

hyc(a)symas.com writes: > I guess that's a fair point, but operating without an entryCSN index would be > a config mistake anyway. (Note that the unchecked limit only has relevance on > backends that support indexing in the first place.) As a user that's a config mistake from which I'd expect poor performance or sizelimit warnings in syslog, not broken CSN handling. In particular when slapo-syncprov(5) does mention indexing without demanding it: "On databases that support inequality indexing, it is helpful to set an eq index on the entryCSN attribute when using this overlay." -- Hallvard

1 0

Re: (ITS#5048) Suspicious use of 'unchecked' limit syncprov
by hyc＠symas.com 13 Jan '11

13 Jan '11

Hallvard B Furuseth wrote: > hyc(a)symas.com writes: >> Wrong. AdminLimitExceeded ONLY means unchecked here. Otherwise it would be >> SizeLimitExceeded (or TimeLimitExceeded). > > Okay. Took me some digging to see that. Anyway, the main problem is > that hitting the unchecked limit does not imply there is an entry which > even approximately matches the filter. Not without indexes. > I guess that's a fair point, but operating without an entryCSN index would be a config mistake anyway. (Note that the unchecked limit only has relevance on backends that support indexing in the first place.) -- -- 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#5048) Suspicious use of 'unchecked' limit syncprov
by h.b.furuseth＠usit.uio.no 13 Jan '11

13 Jan '11

hyc(a)symas.com writes: > Wrong. AdminLimitExceeded ONLY means unchecked here. Otherwise it would be > SizeLimitExceeded (or TimeLimitExceeded). Okay. Took me some digging to see that. Anyway, the main problem is that hitting the unchecked limit does not imply there is an entry which even approximately matches the filter. Not without indexes. -- Hallvard

1 0

(ITS#6787) back-monitor cache locking problem
by hyc＠OpenLDAP.org 12 Jan '11

12 Jan '11

Full_Name: Howard Chu Version: HEAD/RE24 OS: Solaris 10 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (76.94.188.8) Submitted by: hyc As noted on http://www.openldap.org/lists/openldap-devel/201101/msg00033.html back-monitor hangs in test036 (and maybe test039) because it keeps a cached entry locked while sending to the client. It should be releasing the locks before sending the entry. A fix is coming.

1 0

Re: (ITS#6783) back-monitor cache/mutex problem
by hyc＠symas.com 12 Jan '11

12 Jan '11

hyc(a)symas.com wrote: > h.b.furuseth(a)usit.uio.no wrote: >> Full_Name: Hallvard B Furuseth >> Version: HEAD >> OS: Linux x86_64 >> URL: >> Submission from: (NULL) (193.157.198.89) >> Submitted by: hallvard >> >> >> Core dump in back-monitor with LDAP_THREAD_DEBUG when I hit ^C: >> >> ASSERT_OWNER( mutex, "ldap_pvt_thread_mutex_unlock" ); > > I see this too. The Abandon loop's logic is backwards. It's looping from the > current entry to the end of the list and releasing those entries, when it > should only be reasling from the head of the list to the current entry. (I.e., > everything on the tail of the list has not yet been locked by this thread.) > > I'll commit a fix shortly. Never mind, I read this loop wrong. The actual problem is that it calls monitor_cache_release() for volatile entries that had never been locked, and it enters the nonvolatile == 0 loop even when there were no volatile entries. -- -- 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#6783) back-monitor cache/mutex problem
by hyc＠symas.com 12 Jan '11

12 Jan '11

h.b.furuseth(a)usit.uio.no wrote: > Full_Name: Hallvard B Furuseth > Version: HEAD > OS: Linux x86_64 > URL: > Submission from: (NULL) (193.157.198.89) > Submitted by: hallvard > > > Core dump in back-monitor with LDAP_THREAD_DEBUG when I hit ^C: > > ASSERT_OWNER( mutex, "ldap_pvt_thread_mutex_unlock" ); I see this too. The Abandon loop's logic is backwards. It's looping from the current entry to the end of the list and releasing those entries, when it should only be reasling from the head of the list to the current entry. (I.e., everything on the tail of the list has not yet been locked by this thread.) I'll commit a fix shortly. > > #2 ldap_pvt_thread_mutex_unlock (mutex=0x1a526c0) at thr_debug.c:1031 > #3 monitor_cache_release (mi=0x92c8c0, e=0x19ec7f8) at cache.c:389 > #4 monitor_send_children (op=0x236bcb0, rs=0x7f54ce4eea40, > e_parent=0x19ec758, sub=1) at search.c:97 > #5 monitor_back_search (op=0x236bcb0, rs=0x7f54ce4eea40) at search.c:245 > #6 fe_op_search (op=0x236bcb0, rs=0x7f54ce4eea40) at search.c:372 > > That's the o_abandon branch in monitor_send_children(). > > I copied the loop out of the o_abandon branch. test036 crashed with > what I assume is the same problem. No need to hit ^C at the right time: > > Index: back-monitor/search.c > @@ -89,2 +89,9 @@ monitor_send_children( > > + if ( nonvolatile == 0&& (e_tmp = e) != NULL ) { > + do { > + mp = e_tmp->e_private; > + LDAP_PVT_THREAD_ASSERT_MUTEX_OWNER(&mp->mp_mutex ); > + } while ( (e_tmp = mp->mp_next)&& e_tmp != e_nonvolatile ); > + } > + > if ( op->o_abandon ) { > > There is a similar loop further down, I didn't look at that one. > > Variables at the crash: > > e == e_nonvolatile > e_tmp == ((monitor_entry_t *) e->e_private)->mp_next > > *(monitor_entry_t *) e->e_private == { > mp_mutex = {...}, mp_next = 0x261b2a8, mp_children = 0x261b668, > mp_info = 0x8f21c0, mp_flags = 32, mp_cb = 0x0 > } > > *(monitor_entry_t *) e_tmp->e_private == { > mp_mutex = {...}, mp_next = 0x261b2f8, mp_children = 0x261ba28, > mp_info = 0x8f2258, mp_flags = 128, mp_cb = 0x0 > } > > -- -- 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#6786
by masarati＠aero.polimi.it 12 Jan '11

12 Jan '11

There is no evidence in your report of a software error, it is likely a user error. Moreover, OpenLDAP 2.2.23 was discontinued more than 5 years ago; the current release is 2.4.23. Please update and direct software usage questions to openldap-technical(a)openldap.org. This ITS will be closed. p.

1 0

(ITS#6786) OpenLdap 2.2.29 Support for Windows Server 2008
by praveen_kumar.thirunavukkarasu＠alcatel-lucent.com 12 Jan '11

12 Jan '11

Full_Name: Praveen Kumar Version: 2.2.29 OS: Windows Server 2008 R2 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (135.245.168.34) We are using openldap 2.2.29 in our application. It is bundled with our application and is installed with our product installation. Installation of openldap goes smooth and service gets started. But when performing ldapdelete or ldapadd operation the process fails. The logs shows as ldap_bind: Can't contact LDAP server (-1) Not sure if this is because of some security issue when installing in Windows Server 2008. Kindly help me regarding the same and let me know if I need to modify some security setting with Windows. Thanks, Praveen.

1 0

Re: (ITS#6784) Spurious mutex unlock in authzid.c
by masarati＠aero.polimi.it 12 Jan '11

12 Jan '11

Cruft unintentionally left over; fixed in HEAD, thanks. p.

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