openldap-bugs March 2011

openldap-bugs@openldap.org

47 participants
119 discussions

(ITS#6861) slapd and syncrepl performance problem
by jeff_wheeler67＠comcast.net 10 Mar '11

10 Mar '11

Full_Name: Jeff Wheeler Version: 2.4.20 OS: RHEL4.8 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (70.103.136.179) Under ldapsearch/modify load of approximately 160 simultaneous sessions towards the First Master only, after several hours replication falls behind and searches and modifies that previously were <1 second now take 10 seconds+. We see also these messages continually every 5 seconds or so: Mar 10 04:02:05 auvhen2be01 slapd[29178]: => bdb_idl_insert_key: c_put id failed: DB_LOCK_DEADLOCK: Locker killed to resolve a deadlock (-30994) Mar 10 04:02:05 auvhen2be01 slapd[29178]: conn=2249 op=13995: attribute "entryCSN" index add failure LDAP is configured in 2-way multi-master mirrormode on 2 Quad core HP blades with 72GB RAM each. Cache size set to 10GB, id2entry=18GB. The replication agreements are as such: olcSyncrepl: {0}rid=2 provider=ldap://auvhen4be05-traffic.vm.vodafone.net.au b indmethod=simple timeout=0 network-timeout=0 binddn="cn=Directory Manager,o=h 3gau" credentials="admin123" starttls=no filter="(objectclass=*)" searchbase= "o=h3gau" scope=sub schemachecking=off type=refreshAndPersist retry="60 +" .. olcOverlay: {0}syncprov olcSpCheckpoint: 100 600 .. Eventually, the syncrepl connection goes to TIME_WAIT state and replications stop. Restarting slapd does not fix and we have to reload from backup. We tuned the following and no longer does slapd repl connection go to TIME_WAIT, however it still falls hours behind on updates and performs slowly as before. Cache size set to 20GB, olcDbIDLcacheSize: 20000000000, olcThreads: 32 Restarting slapd results in the repl connection binding, searching, but then unbinds immediately: Mar 11 03:20:57 auvhen4be05 slapd[25786]: conn=2040 fd=19 ACCEPT from IP=10.176.77.23:50798 (IP=10.176.77.47:389) Mar 11 03:20:57 auvhen4be05 slapd[25786]: conn=2040 op=0 BIND dn="cn=directory manager,o=h3gau" method=128 Mar 11 03:20:57 auvhen4be05 slapd[25786]: conn=2040 op=0 BIND dn="cn=directory manager,o=h3gau" mech=SIMPLE ssf=0 Mar 11 03:20:57 auvhen4be05 slapd[25786]: conn=2040 op=0 RESULT tag=97 err=0 text= Mar 11 03:20:57 auvhen4be05 slapd[25786]: conn=2040 op=1 SRCH base="o=h3gau" scope=2 deref=0 filter="(objectClass=*)" Mar 11 03:20:57 auvhen4be05 slapd[25786]: conn=2040 op=1 SRCH attr=* + Mar 11 03:20:57 auvhen4be05 slapd[25786]: conn=2040 op=1 SEARCH RESULT tag=101 err=0 nentries=0 text= Mar 11 03:20:57 auvhen4be05 slapd[25786]: conn=2040 op=2 UNBIND Mar 11 03:20:57 auvhen4be05 slapd[25786]: conn=2040 fd=19 closed

1 0

Re: (ITS#6860) slapadd accepts duplicate objectclasses
by hyc＠symas.com 10 Mar '11

10 Mar '11

dieter(a)dkluenter.de wrote: > Full_Name: Dieter Klünter > Version: 2.4.24 > OS: SLES11_x64 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (84.142.18.17) > > > A ldif generator created out of a total of 100,000 entries 10,000 entries with > duplicate objectclasses i.e. > > dn: cn=Michelina Al-Basi,ou=Accounting,ou=bremen,dc=dkluenter,dc=de > objectClass: top > objectClass: person > objectClass: organizationalPerson > objectClass: inetOrgPerson > objectClass: top > objectClass: person > objectClass: organizationalPerson > objectClass: inetOrgPerson > cn: Al-BasiM > sn: Al-Basi > > This ldif has been loaded by slapadd without any warnings. The only parameter > applied where -l and -f. This is normal. slapadd doesn't do validation, you are expected to feed it valid output from slapcat. This documented behavior has not changed in a decade. Closing this ITS. -- -- 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#6860) slapadd accepts duplicate objectclasses
by dieter＠dkluenter.de 10 Mar '11

10 Mar '11

Full_Name: Dieter Klünter Version: 2.4.24 OS: SLES11_x64 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (84.142.18.17) A ldif generator created out of a total of 100,000 entries 10,000 entries with duplicate objectclasses i.e. dn: cn=Michelina Al-Basi,ou=Accounting,ou=bremen,dc=dkluenter,dc=de objectClass: top objectClass: person objectClass: organizationalPerson objectClass: inetOrgPerson objectClass: top objectClass: person objectClass: organizationalPerson objectClass: inetOrgPerson cn: Al-BasiM sn: Al-Basi This ldif has been loaded by slapadd without any warnings. The only parameter applied where -l and -f. -Dieter

1 0

Re: (ITS#6859) ldap_int_thread_mutex_x functions introduced in 2.4, 24
by dvladi＠websense.com 09 Mar '11

09 Mar '11

--_000_36C3E4EA3ECF49F68EBD3A7AC0A7D60Dwebsensecom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable You are right, ldap_int_thread_mutex_(X) functions were introduced in 2.3.8= on 10/06/2005. But there is NO declaration or function definition anywhere in the code. What was changed is 2.4.24 is ldap_int_initialize_global_options function. A call to LDAP_PVT_MUTEX_FIRSTCREATE(gopts->ldo_mutex) was added. That macro (With defined HAVE_NT_THREADS) resolves to ldap_int_thread_mutex= _init. Since that function does not exist my linker reports an error. Here is what's going on LDAP_PVT_MUTEX_FIRSTCREATE is defined in include/ldap_pvt_thread.h as LDAP_= DEBUG_MUTEX_FIRSTCREATE (if LDAP_PVT_THREAD_H_DONE is not defined and LDAP_= THREAD_DEBUG_WRAP is defined) or LDAP_INT_MUTEX_FIRSTCREATE (if both LDAP_P= VT_THREAD_H_DONE and LDAP_THREAD_DEBUG_WRAP are defined). The last one is m= y case, I could not find any definition or information on whether or not LD= AP_PVT_THREAD_H_DONE should be defined. For HAVE_NT_THREADS LDAP_INT_MUTEX_FIRSTCREATE is resolved as (include/ldap= _int_thread.h:185) #elif defined(HAVE_NT_THREADS) /************************************* * * * thread definitions for NT threads * * * *************************************/ #include <process.h> #include <windows.h> LDAP_BEGIN_DECL typedef unsigned long ldap_int_thread_t; typedef HANDLE ldap_int_thread_mutex_t; typedef HANDLE ldap_int_thread_cond_t; typedef DWORD ldap_int_thread_key_t; #ifndef LDAP_INT_MUTEX_NULL #define LDAP_INT_MUTEX_NULL ((HANDLE)0) #define LDAP_INT_MUTEX_FIRSTCREATE(m) \ ((void) ((m) || ldap_int_thread_mutex_init(&(m)))) #endif And since there is no function ldap_int_thread_mutex_init linker fails. Sincerelly Demian Vladi ----- Reply message ----- From: "openldap-its(a)OpenLDAP.org" <openldap-its(a)OpenLDAP.org> Date: Wed, Mar 9, 2011 4:01 pm Subject: (ITS#6859) ldap_int_thread_mutex_x functions introduced in 2.4,24 To: "Vladi, Demian" <dvladi(a)websense.com> *** 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#6859. 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#6859) in the subject will automatically be attached to the issue report. mailto:openldap-its@openldap.org?subject=3D(ITS#6859) 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=3D6859 Please remember to retain your issue tracking number (ITS#6859) 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. To report this as spam, please forward to spam(a)websense.com. Thank you. Protected by Websense Hosted Email Security -- www.websense.com=20 --_000_36C3E4EA3ECF49F68EBD3A7AC0A7D60Dwebsensecom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <html> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Diso-8859-= 1"> <meta name=3D"Generator" content=3D"Microsoft Exchange Server"> <style></style> </head> <body> <style>  </style> <div> You are right, ldap_int_thread_mutex_(X) functions were introduced in 2.3.8= on 10/06/2005. But there is NO declaration or function definition anywhere in the code. What was changed is 2.4.24 is ldap_int_initialize_global_options function.<= br> A call to LDAP_PVT_MUTEX_FIRSTCREATE(gopts->ldo_mutex) was added. That macro (With defined HAVE_NT_THREADS) resolves to ldap_int_thread_mutex= _init. Since that function does not exist my linker reports an error. Here is what's going on LDAP_PVT_MUTEX_FIRSTCREATE is defined in include/ldap_pvt_thread.h as LDAP_= DEBUG_MUTEX_FIRSTCREATE (if LDAP_PVT_THREAD_H_DONE is not defined and LDAP_= THREAD_DEBUG_WRAP is defined) or LDAP_INT_MUTEX_FIRSTCREATE (if both LDAP_P= VT_THREAD_H_DONE and LDAP_THREAD_DEBUG_WRAP are defined). The last one is my case, I could not find any definition or = information on whether or not LDAP_PVT_THREAD_H_DONE should be defined. For HAVE_NT_THREADS LDAP_INT_MUTEX_FIRSTCREATE is resolved as (include/ldap= _int_thread.h:185) #elif defined(HAVE_NT_THREADS) /*************************************  *           &n= bsp;           &nbsp= ;           *  * thread definitions for NT threads *  *           &n= bsp;           &nbsp= ;           *  *************************************/ #include <process.h> #include <windows.h> LDAP_BEGIN_DECL typedef unsigned long   ldap_int_thread_t; typedef HANDLE  ldap_int_thread_mutex_t; typedef HANDLE  ldap_int_thread_cond_t; typedef DWORD   ldap_int_thread_key_t; #ifndef LDAP_INT_MUTEX_NULL #define LDAP_INT_MUTEX_NULL        =      ((HANDLE)0) #define LDAP_INT_MUTEX_FIRSTCREATE(m) \             &nb= sp;   ((void) ((m) || ldap_int_thread_mutex_init(&(m)))) #endif And since there is no function ldap_int_thread_mutex_init linker fails. Sincerelly Demian Vladi <div id=3D"x_htc_header" style=3D"">----- Reply message ----- From: "openldap-its(a)OpenLDAP.org" <openldap-its(a)OpenLDAP.org&g= t; Date: Wed, Mar 9, 2011 4:01 pm Subject: (ITS#6859) ldap_int_thread_mutex_x functions introduced in 2.4,24<= br> To: "Vladi, Demian" <dvladi(a)websense.com> </div> </div> <div class=3D"PlainText"> *** 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#6859. 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#6859) in the subject will automatically be attached to the issue report.         <a href=3D"mailto:openldap-its@o= penldap.org?subject=3D(ITS#6859">mailto:openldap-its@openldap.org?subject= =3D(ITS#6859</a>) You may follow the progress of this report by loading the following URL in a web browser:     <a href=3D"http://www.OpenLDAP.org/its/index.cgi?findid= =3D6859">http://www.OpenLDAP.org/its/index.cgi?findid=3D6859</a> Please remember to retain your issue tracking number (ITS#6859) 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.         <a href=3D"http://www.OpenLDAP.o= rg/support/">http://www.OpenLDAP.org/support/</a> -------------- Copyright 1998-2007 The OpenLDAP Foundation, All Rights Reserved.  To report this as spam, please forward to spam(a)websense.com.  Th= ank you. </div> Protected by Websense Hosted Email Security &#8= 212; www.websense.com </body> </html> --_000_36C3E4EA3ECF49F68EBD3A7AC0A7D60Dwebsensecom_--

1 0

Re: (ITS#6859) ldap_int_thread_mutex_x functions introduced in 2.4, 24
by hyc＠symas.com 09 Mar '11

09 Mar '11

dvladi(a)websense.com wrote: > Full_Name: Demian Vladi > Version: 2.4.24 > OS: Windwos > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (204.15.64.155) > > > My program that uses openLdap fails to link for me due to unresolved > ldap_int_thread_mutex_(X) functions, e.g ldap_int_thread_mutex_init. > It looks like they were introduced in 2.4.24, but there is no definition or > declaration for them :( > You're mistaken, these definitions were introduced many years ago. Long before 2.4.24. Long before 2.3 even. Sounds like you're linking incorrectly. No bug here, this ITS will be closed. For help with usage questions please post on the openldap-technical mailing list. -- -- 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#6859) ldap_int_thread_mutex_x functions introduced in 2.4,24
by dvladi＠websense.com 09 Mar '11

09 Mar '11

Full_Name: Demian Vladi Version: 2.4.24 OS: Windwos URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (204.15.64.155) My program that uses openLdap fails to link for me due to unresolved ldap_int_thread_mutex_(X) functions, e.g ldap_int_thread_mutex_init. It looks like they were introduced in 2.4.24, but there is no definition or declaration for them :(

1 0

Re: (ITS#6853) slapadd/slapindex -q hang
by quanah＠zimbra.com 09 Mar '11

09 Mar '11

--On March 9, 2011 9:42:18 AM -0800 Howard Chu <hyc(a)symas.com> wrote: > Quanah Gibson-Mount wrote: >> >> >> --On March 4, 2011 11:14:46 PM +0000 dhawes(a)vt.edu wrote: >>> Tested, and working. Thanks for the fix. >> >> We're still seeing this happen sporadically with slapindex -q<attribute> >> >> i.e., reindexing a single attribute instead of the entire DB > > Can't reproduce it here, need a test case. It's hard to come up with one. We've only had this one instance on one machine. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6853) slapadd/slapindex -q hang
by hyc＠symas.com 09 Mar '11

09 Mar '11

Quanah Gibson-Mount wrote: > > > --On March 4, 2011 11:14:46 PM +0000 dhawes(a)vt.edu wrote: >> Tested, and working. Thanks for the fix. > > We're still seeing this happen sporadically with slapindex -q<attribute> > > i.e., reindexing a single attribute instead of the entire DB Can't reproduce it here, need a test case. -- -- 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#6461) back-sql quote characters in query
by hyc＠symas.com 09 Mar '11

09 Mar '11

atze_80(a)web.de wrote: > Can confirm this with openldap 2.4.24. Thanks, the bug was already confirmed. > > Using ldap search filters like this: > > (cn=blabla' or '1'='1) > > is at least causing my postgres to eat all CPU cycles it can get (LDAP > data is based on complex view). I do not have write access enabled for > that particular openLDAP installation, but I also assume that SQL > Injection is possible. Beside being an obviuos malfunction, this should > be considered a security issue. As the bug status says, "patches welcome." back-sql is not a priority for any of the core developers. -- -- 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#6858) segfault on schema modification in cn=config
by hyc＠symas.com 09 Mar '11

09 Mar '11

zerbe(a)phil.uni-duesseldorf.de wrote: > Full_Name: Sebastian Zerbe > Version: 2.4.23-7 > OS: Debian GNU/Linux 6.0 > URL: ftp://ftp.openldap.org/incoming/sebastian-zerbe-110309.tar.gz > Submission from: (NULL) (134.99.58.27) > > > Trying to modify the local schema cn={5}philfak,cn=schema,cn=config with the > given ldif-file modify_phil_schema.ldif using "ldapmodify -x -D > cn=admin,cn=config -W -f modify_phil_schema.ldif" results in a slapd crash with > kernel log entries like these: > > [3451954.217075] slapd[2593]: segfault at 70 ip 080bd73f sp ae5f9910 error 4 in > slapd[8048000+11b000] > [3451972.088717] slapd[5716]: segfault at 70 ip 080bd73f sp b1bfe910 error 4 in > slapd[8048000+11b000] > [3452718.916547] slapd[5830]: segfault at 70 ip 080bd73f sp b1992910 error 4 in > slapd[8048000+11b000] > > Further debugging is nearly impossible. If slapd is running in gdb it does not > crash (but the modifications do not take place either)... The crash has been fixed in HEAD, but your mod request will still fail because Delete is not supported for olcObjectIdentifier attributes. -- -- 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

← Newer
1
...
5
6
7
8
9
10
11
12
Older →

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs March 2011