openldap-bugs January 2011

openldap-bugs@openldap.org

36 participants
177 discussions

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

(ITS#6785) slapo-chain mishandles sr_text/sr_matched
by h.b.furuseth＠usit.uio.no 12 Jan '11

12 Jan '11

Full_Name: Hallvard B Furuseth Version: HEAD OS: URL: Submission from: (NULL) (193.157.198.89) Submitted by: hallvard ldap_chain_response() can send sr_text/sr_matched which refers to a different error than sr_err and rc. It saves rs-> sr_err, sr_text, sr_matched to three local variables and can restore them later, but not maintain the text and matched variables in parallel with err. Also it does not track/reset/obey REP_MATCHED_MUSTBEFREED along with sr_matched. Fails test032-chain with the asserts below. However there may be non-success result with the wrong text/matched too, that cannot be assert()ed. Come to think of it, maybe the last issues applies to ITS#6774 too? REP_MATCHED_MUSTBEFREED, mismatch between failure code and text/matched. Index: servers/slapd/back-ldap/chain.c @@ -1019,4 +1019,14 @@ ldap_chain_response( Operation *op, SlapReply *rs ) rs->sr_ref = NULL; + const char *bad_incoming_matched = NULL, *bad_incoming_text = NULL; + switch ( sr_err ) { + case LDAP_SUCCESS: + case LDAP_COMPARE_TRUE: + case LDAP_COMPARE_FALSE: + bad_incoming_matched = matched; + case LDAP_REFERRAL: + bad_incoming_text = text; + } + /* we need this to know if back-ldap returned any result */ lb.lb_lc = lc; @@ -1169,4 +1179,15 @@ cannot_chain:; dont_chain:; + switch ( sr_err ) { + case LDAP_SUCCESS: + case LDAP_COMPARE_TRUE: + case LDAP_COMPARE_FALSE: + assert( !matched || bad_incoming_matched ); + case LDAP_REFERRAL: + assert( !text || bad_incoming_text ); + } + assert( rc != LDAP_SUCCESS || + (( !text || bad_incoming_text) && + ( !matched || bad_incoming_matched ))); rs->sr_err = sr_err; rs->sr_type = sr_type;

1 0

(ITS#6784) Spurious mutex unlock in authzid.c
by h.b.furuseth＠usit.uio.no 12 Jan '11

12 Jan '11

Full_Name: Hallvard B Furuseth Version: HEAD OS: URL: Submission from: (NULL) (193.157.198.89) Submitted by: hallvard authzid_conn_find() in contrib/slapd-modules/authzid/authzid.c can do ldap_pvt_thread_mutex_unlock( &authzid_mutex ); even though every code path from ldap_pvt_thread_mutex_lock( &authzid_mutex ); elsewhere in authzid.c leads to an unlock statement of its own.

1 0

← Newer
1
...
9
10
11
12
13
14
15
...
18
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs January 2011