openldap-bugs

openldap-bugs@openldap.org

1 participants
20969 discussions

Re: (ITS#7085) mutex lockup issue
by quanah＠zimbra.com 09 Nov '11

09 Nov '11

--On Wednesday, November 09, 2011 2:01 PM +0000 hayashis(a)indiana.edu wrote: > Full_Name: Soichi Hayashi > Version: 2.4.22 OpenLDAP 2.4.22 is quite old, and had various known issues. Please use a current release (2.4.26). This report will not be investigated unless you can reproduce it with a current release of OpenLDAP. You also fail to note what BDB release you are using, and whether or not it has all the relevant patches applied to it. If you have a broken policy of only using vendor provided packages, then you will need to send a bug report to RedHat, as it is their job to maintain their vendor packages. Thanks! --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#7074) back-ldap module compilation issue with gcc 4.6.1
by stephane.paquot＠gmail.com 09 Nov '11

09 Nov '11

--90e6ba613518beaf2904b14dee12 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Howard, Compilation is fine and module back-ldap is fully operational with the workaround you have suggested. Many thanks to you. 2011/10/29 <openldap-its(a)openldap.org> > > *** THIS IS AN AUTOMATICALLY GENERATED REPLY *** > > Thanks for your report to the OpenLDAP Issue Tracking System. Your > report has been assigned the tracking number ITS#7074. > > One of our support engineers will look at your report in due course. > Note that this may take some time because our support engineers > are volunteers. They only work on OpenLDAP when they have spare > time. > > If you need to provide additional information in regards to your > issue report, you may do so by replying to this message. Note that > any mail sent to openldap-its(a)openldap.org with (ITS#7074) > in the subject will automatically be attached to the issue report. > > mailto:openldap-its@openldap.org?subject=3D(ITS#7074) > > You may follow the progress of this report by loading the following > URL in a web browser: > http://www.OpenLDAP.org/its/index.cgi?findid=3D7074 > > Please remember to retain your issue tracking number (ITS#7074) > on any further messages you send to us regarding this report. If > you don't then you'll just waste our time and yours because we > won't be able to properly track the report. > > Please note that the Issue Tracking System is not intended to > be used to seek help in the proper use of OpenLDAP Software. > Such requests will be closed. > > OpenLDAP Software is user supported. > http://www.OpenLDAP.org/support/ > > -------------- > Copyright 1998-2007 The OpenLDAP Foundation, All Rights Reserved. > > --=20 _________________________________ St=E9phane PAQUOT stephane.paquot(a)gmail.com Site web : http://www.sqlpac.com/ --90e6ba613518beaf2904b14dee12 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <div>Hi Howard,</div><div><br></div><div>Compilation is fine and module bac= k-ldap is fully operational with the workaround you have suggested.</div><d= iv><br></div><div>Many thanks to you.</div><div><br></div><br><div class=3D= "gmail_quote"> 2011/10/29 <span dir=3D"ltr"><<a href=3D"mailto:openldap-its@openldap.o= rg">openldap-its(a)openldap.org</a>></span><br><blockquote class=3D"gmail_= quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1= ex;"> <br> *** THIS IS AN AUTOMATICALLY GENERATED REPLY ***<br> <br> Thanks for your report to the OpenLDAP Issue Tracking System. =A0Your<br> report has been assigned the tracking number ITS#7074.<br> <br> One of our support engineers will look at your report in due course.<br> Note that this may take some time because our support engineers<br> are volunteers. =A0They only work on OpenLDAP when they have spare<br> time.<br> <br> If you need to provide additional information in regards to your<br> issue report, you may do so by replying to this message. =A0Note that<br> any mail sent to <a href=3D"mailto:openldap-its@openldap.org">openldap-its@= openldap.org</a> with (ITS#7074)<br> in the subject will automatically be attached to the issue report.<br> <br> =A0 =A0 =A0 =A0mailto:<a href=3D"mailto:openldap-its@openldap.org">openlda= p-its(a)openldap.org</a>?subject=3D(ITS#7074)<br> <br> You may follow the progress of this report by loading the following<br> URL in a web browser:<br> =A0 =A0<a href=3D"http://www.OpenLDAP.org/its/index.cgi?findid=3D7074" tar= get=3D"_blank">http://www.OpenLDAP.org/its/index.cgi?findid=3D7074</a><br> <br> Please remember to retain your issue tracking number (ITS#7074)<br> on any further messages you send to us regarding this report. =A0If<br> you don't then you'll just waste our time and yours because we<br> won't be able to properly track the report.<br> <br> Please note that the Issue Tracking System is not intended to<br> be used to seek help in the proper use of OpenLDAP Software.<br> Such requests will be closed.<br> <br> OpenLDAP Software is user supported.<br> =A0 =A0 =A0 =A0<a href=3D"http://www.OpenLDAP.org/support/" target=3D"_bla= nk">http://www.OpenLDAP.org/support/</a><br> <br> --------------<br> Copyright 1998-2007 The OpenLDAP Foundation, All Rights Reserved.<br> <br> </blockquote></div><br><br clear=3D"all"><div><br></div>-- <br>____________= _____________________<br><br>St=E9phane PAQUOT<br><br><a href=3D"mailto:ste= phane.paquot(a)gmail.com">stephane.paquot(a)gmail.com</a><br>Site web : <a href= =3D"http://www.sqlpac.com/">http://www.sqlpac.com/</a><br> <br> --90e6ba613518beaf2904b14dee12--

1 0

(ITS#7085) mutex lockup issue
by hayashis＠indiana.edu 09 Nov '11

09 Nov '11

Full_Name: Soichi Hayashi Version: 2.4.22 OS: RHEL 5.7 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (99.137.202.79) When a large number of ldap update requests collides with large number of ldap search queries, mutex on BDB linked to OpenLDAP deadlocks. Following is the gdb output when this deadlocks occurs. (gdb) info threads 13 Thread 0x40a73940 (LWP 18767) 0x00000037aa4d48a8 in epoll_wait () from /lib64/libc.so.6 12 Thread 0x41cbe940 (LWP 18768) 0x00000037aa4cd722 in select () from /lib64/libc.so.6 11 Thread 0x424bf940 (LWP 18769) 0x00000037aac0aee9 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 10 Thread 0x42cc0940 (LWP 19203) 0x00000037aac0aee9 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 9 Thread 0x41274940 (LWP 19212) 0x00000037aac0aee9 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 8 Thread 0x434c1940 (LWP 19213) 0x00000037aac0aee9 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 7 Thread 0x43cc2940 (LWP 19214) 0x00000037aac0aee9 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 6 Thread 0x444c3940 (LWP 19215) 0x00000037aac0aee9 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 5 Thread 0x44cc4940 (LWP 19216) 0x00000037aac0aee9 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 4 Thread 0x454c5940 (LWP 19217) 0x00000037aac0a256 in pthread_rwlock_rdlock () from /lib64/libpthread.so.0 3 Thread 0x45cc6940 (LWP 19218) 0x00000037aac0aee9 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 2 Thread 0x464c7940 (LWP 19219) 0x00000037aac0a4c0 in pthread_rwlock_wrlock () from /lib64/libpthread.so.0 * 1 Thread 0x2ad9964071e0 (LWP 18752) 0x00000037aac07b35 in pthread_join () from /lib64/libpthread.so.0 (gdb) thread 2 [Switching to thread 2 (Thread 0x464c7940 (LWP 19219))]#0 0x00000037aac0a4c0 in pthread_rwlock_wrlock () from /lib64/libpthread.so.0 (gdb) bt #0 0x00000037aac0a4c0 in pthread_rwlock_wrlock () from /lib64/libpthread.so.0 #1 0x0000003f22c2b963 in __db_pthread_mutex_lock_openldap_slapd24_mdv () from /usr/lib64/libslapd24_db-4.8.so #2 0x0000003f22d1e2dc in __memp_fget_openldap_slapd24_mdv () from /usr/lib64/libslapd24_db-4.8.so #3 0x0000003f22c46a8f in __bam_search_openldap_slapd24_mdv () from /usr/lib64/libslapd24_db-4.8.so #4 0x0000003f22c34649 in ?? () from /usr/lib64/libslapd24_db-4.8.so #5 0x0000003f22c3534b in ?? () from /usr/lib64/libslapd24_db-4.8.so #6 0x0000003f22cd4bbf in __dbc_iput_openldap_slapd24_mdv () from /usr/lib64/libslapd24_db-4.8.so #7 0x0000003f22cd536f in __dbc_put_openldap_slapd24_mdv () from /usr/lib64/libslapd24_db-4.8.so #8 0x0000003f22cdca0f in __dbc_put_pp_openldap_slapd24_mdv () from /usr/lib64/libslapd24_db-4.8.so #9 0x00000000004c9d7e in bdb_idl_insert_key () #10 0x00000000004cbcb2 in bdb_key_change () (gdb) thread 4 [Switching to thread 4 (Thread 0x454c5940 (LWP 19217))]#0 0x00000037aac0a256 in pthread_rwlock_rdlock () from /lib64/libpthread.so.0 (gdb) bt #0 0x00000037aac0a256 in pthread_rwlock_rdlock () from /lib64/libpthread.so.0 #1 0x0000003f22c2b754 in __db_pthread_mutex_readlock_openldap_slapd24_mdv () from /usr/lib64/libslapd24_db-4.8.so #2 0x0000003f22d1e5fc in __memp_fget_openldap_slapd24_mdv () from /usr/lib64/libslapd24_db-4.8.so #3 0x0000003f22cd3df9 in __dbc_iget_openldap_slapd24_mdv () from /usr/lib64/libslapd24_db-4.8.so #4 0x0000003f22cdd43a in __dbc_get_pp_openldap_slapd24_mdv () from /usr/lib64/libslapd24_db-4.8.so #5 0x00000000004ca6d0 in bdb_idl_fetch_key () #6 0x00000000004cbd75 in bdb_key_read () In above case, thread 2 and thread 4 are deadlocked. The deadlock occurs within 2 - 8 hours after we start testing LDAP server on our BDII services. Meanwhile, OpenLDAP version 2.3 does not cause this deadlock, but it causes a gradual CPU usage increase until the performance degrades to the point where we need to restart the server. Is there anyway you could fix the deadlock issue on v2.4, or CPU usage issue on v2.3? Thanks, Soichi Hayashi

1 0

(ITS#7084) Password Modify Extended Operation to set pwdReset: TRUE
by michael＠stroeder.com 08 Nov '11

08 Nov '11

Full_Name: Version: OS: URL: Submission from: (NULL) (192.166.104.102) Feature Request: The Password Modify Extended Operation should set pwdReset: TRUE if the accompanying password policy specifies pwdMustChange: TRUE. Section 8.2.7 of http://tools.ietf.org/html/draft-behera-ldap-password-policy-09#section-8.2 says: If the value the pwdMustChange is TRUE and the modification is performed by a password administrator, then the pwdReset attribute is set to TRUE. Otherwise, the pwdReset is removed from the user's entry if it exists. So the question is how to determine whether the modification is performed by a password administrator. There could be an attribute in the password policy entry with values like authzTo/authzFrom to specify the set of password admins.

1 0

Re: (ITS#7082) smbk5pwd not respecting olcSmbK5PwdEnable on 64-bit platforms
by h.b.furuseth＠usit.uio.no 07 Nov '11

07 Nov '11

Thank you. I've committed your fix. verbs_to_mask() adds bits to an existing mask. > (...) I'm not sure why this only > manifests on 64-bit architectures, as my reduced test case (can > provide if necessary) also fails on 32-bit architectures. Probably just a coincidence: There happens to be a 0 on the stack where the compiler puts the m variable on on your 32-bit hosts. -- Hallvard

1 0

(ITS#7083) Broken verb_to_mask() calls
by h.b.furuseth＠usit.uio.no 07 Nov '11

07 Nov '11

Full_Name: Hallvard B Furuseth Version: 2.3-2.4.26 OS: URL: Submission from: (NULL) (193.71.61.60) Submitted by: hallvard slapd/bconfig.c and contrib:smbk5pwd.c use verb_to_mask() as if it returned a bitmask instead of an index. This affects delete operations of restrict, allows, disallows, requires, syslog loglevel, and smbk5pwd modules.

1 0

(ITS#7082) smbk5pwd not respecting olcSmbK5PwdEnable on 64-bit platforms
by zanchey＠ucc.gu.uwa.edu.au 07 Nov '11

07 Nov '11

Full_Name: David Adam Version: 2.4.23 OS: Debian URL: http://www.openldap.org/lists/openldap-technical/201111/msg00034.html Submission from: (NULL) (2001:44b8:6112:bc00:6ef0:49ff:fe74:26c4) On 64-bit machines using the contributed smbk5pwd overlay, the smbk5pwd module insists on trying to load all the Kerberos configuration regardless, even if smbk5PwdEnable is set to 'samba'. I suspect this has something to do with the call to verbs_to_mask() in smbk5pwd_cf_func (under the case PC_SMB_ENABLE) - my very basic printf() debugging shows that m is set correctly on 32-bit architectures but on 64-bit architectures returns a varying and strangely-numbered value (4511419, -1407332384, 353253328 in subsequent runs). The problem goes away if the m variable is initialised to 0 before the call to verbs_to_mask(). Most of the calls to verbs_to_mask() in the rest of the source initialise the fourth variable to 0 before calling. Either smbk5pwd also needs to do this, or the verbs_to_mask function needs to initialise the variable before use. I'm not sure why this only manifests on 64-bit architectures, as my reduced test case (can provide if necessary) also fails on 32-bit architectures.

1 0

Re: (ITS#7081) test020-proxycache failed for bdb
by hyc＠symas.com 04 Nov '11

04 Nov '11

michael(a)stroeder.com wrote: > Full_Name: > Version: > OS: > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (84.128.242.48) > > > Seems there's a regression in HEAD's slapo-pcache possibly due to the recent > commits. Thanks for the report, fixed in master. > >>>>>> Starting test020-proxycache for bdb... > Starting master slapd on TCP/IP port 9011... > Using ldapsearch to check that master slapd is running... > Using ldapadd to populate the master directory... > Starting proxy cache on TCP/IP port 9012... > Using ldapsearch to check that proxy slapd is running... > Making queries on the proxy cache... > Query 1: filter:(sn=Jon) attrs:all (expect nothing) > Query 2: filter:(|(cn=*Jon*)(sn=Jon*)) attrs:cn sn title uid > Query 3: filter:(sn=Smith*) attrs:cn sn uid > Query 4: filter:(sn=Doe*) attrs:cn sn title uid > Query 5: filter:(uid=johnd) attrs:mail postaladdress telephonenumber cn uid > Query 6: filter:(mail=*@mail.alumni.example.com) attrs:cn sn title uid > Query 7: filter:(mail=*) attrs:cn sn title uid > Query 8: filter:(mail=*example.com) attrs:cn sn title uid > ldapsearch failed (4) > Query 9: filter:(uid=b*) attrs:mail > ldapsearch failed (4) > Query 10: filter:(|(cn=All Staff)(sn=All Staff)) attrs:sn cn title uid > undefinedAttr > Query 1 not cacheable > Query 2 cacheable > Query 3 cacheable > Query 4 cacheable > Query 5 cacheable > Query 6 cacheable > Query 7 not cacheable > Query 8 cacheable > Query 9 cacheable > Query 10 cacheable > Successfully verified cacheability > Query 11: filter:(|(cn=*Jones)(sn=Jones)) attrs:cn sn title uid > Query 12: filter:(sn=Smith) attrs:cn sn title uid > Query 13: filter:(uid=bjorn) attrs:mail postaladdress telephonenumber cn uid > Query 14: filter:(mail=jaj@mail.alumni.example.com) attrs:cn sn title uid > Query 15: filter:(mail=*example.com) attrs:cn sn title uid > ldapsearch failed (4) > Query 16: filter:(uid=b*) attrs:mail > ldapsearch should have failed! >>>>>> test020-proxycache failed for bdb > (exit 1) > make[2]: *** [bdb-mod] Error 1 > make[2]: Leaving directory `/usr/src/michael/openldap/tests' > make[1]: *** [test] Error 2 > make[1]: Leaving directory `/usr/src/michael/openldap/tests' > make: *** [test] Error 2 > m > > -- -- 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#7081) test020-proxycache failed for bdb
by michael＠stroeder.com 04 Nov '11

04 Nov '11

Full_Name: Version: OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (84.128.242.48) Seems there's a regression in HEAD's slapo-pcache possibly due to the recent commits. >>>>> Starting test020-proxycache for bdb... Starting master slapd on TCP/IP port 9011... Using ldapsearch to check that master slapd is running... Using ldapadd to populate the master directory... Starting proxy cache on TCP/IP port 9012... Using ldapsearch to check that proxy slapd is running... Making queries on the proxy cache... Query 1: filter:(sn=Jon) attrs:all (expect nothing) Query 2: filter:(|(cn=*Jon*)(sn=Jon*)) attrs:cn sn title uid Query 3: filter:(sn=Smith*) attrs:cn sn uid Query 4: filter:(sn=Doe*) attrs:cn sn title uid Query 5: filter:(uid=johnd) attrs:mail postaladdress telephonenumber cn uid Query 6: filter:(mail=*@mail.alumni.example.com) attrs:cn sn title uid Query 7: filter:(mail=*) attrs:cn sn title uid Query 8: filter:(mail=*example.com) attrs:cn sn title uid ldapsearch failed (4) Query 9: filter:(uid=b*) attrs:mail ldapsearch failed (4) Query 10: filter:(|(cn=All Staff)(sn=All Staff)) attrs:sn cn title uid undefinedAttr Query 1 not cacheable Query 2 cacheable Query 3 cacheable Query 4 cacheable Query 5 cacheable Query 6 cacheable Query 7 not cacheable Query 8 cacheable Query 9 cacheable Query 10 cacheable Successfully verified cacheability Query 11: filter:(|(cn=*Jones)(sn=Jones)) attrs:cn sn title uid Query 12: filter:(sn=Smith) attrs:cn sn title uid Query 13: filter:(uid=bjorn) attrs:mail postaladdress telephonenumber cn uid Query 14: filter:(mail=jaj@mail.alumni.example.com) attrs:cn sn title uid Query 15: filter:(mail=*example.com) attrs:cn sn title uid ldapsearch failed (4) Query 16: filter:(uid=b*) attrs:mail ldapsearch should have failed! >>>>> test020-proxycache failed for bdb (exit 1) make[2]: *** [bdb-mod] Error 1 make[2]: Leaving directory `/usr/src/michael/openldap/tests' make[1]: *** [test] Error 2 make[1]: Leaving directory `/usr/src/michael/openldap/tests' make: *** [test] Error 2 m

1 0

(ITS#7080) post read control in back-config
by michael＠stroeder.com 03 Nov '11

03 Nov '11

Full_Name: Version: OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (84.163.60.140) back-config should support the post read control so that applications can determine the possibly renumbered DN after adding/modifying an entry

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