openldap-bugs

openldap-bugs@openldap.org

1 participants
20964 discussions

Re: (ITS#6851) back-ldap assertion failure, LDAP proxy to Windows AD
by tedcheng＠symas.com 17 Nov '11

17 Nov '11

The following patch fixed the issue: Index: servers/slapd/back-ldap/bind.c =================================================================== RCS file: /var/CVSROOT/ldap24/servers/slapd/back-ldap/bind.c,v retrieving revision 1.12 retrieving revision 1.13 diff -u -u -r1.12 -r1.13 --- servers/slapd/back-ldap/bind.c 28 Jul 2011 09:31:34 -0000 1.12 +++ servers/slapd/back-ldap/bind.c 17 Nov 2011 21:35:46 -0000 1.13 @@ -2056,7 +2056,7 @@ struct berval ndn; int dobind = 0; - if ( op->o_conn == NULL || op->o_do_not_cache ) { + if ( op->o_conn == NULL ) { goto done; } Ted C. Cheng Symas Corporation

1 0

Re: (ITS#7025) "the backglue code doesn't install a handler for the Abandon operation"
by hyc＠symas.com 17 Nov '11

17 Nov '11

hyc(a)symas.com wrote: > Marc Patermann wrote: >> Howard, >> >> Howard Chu schrieb (01.11.2011 18:39 Uhr): >> >>> Also, this script just performs sync searches, what do you use to >>> generate the writes? >> you mean the write which kills the server? >> It just one simple mod of an object which I made in Apache Directory Studio. > > I'm unable to reproduce this crash. I have your slapd.conf and test data, I > have run 80-some instances of your script as you've described. While the > initial sync search is running I perform a modify of the base entry of the > subordinate database. Everything continues to run. I've also waited for all of > the initial refresh traffic to finish first, and then perform the modify, and > still no crash. > > To be more clear - do you perform your modify while the sync searches are > still refreshing, or after all of the refreshes have completed? > > Do you run the clients on the same host as slapd, or on a remote machine? By the way... Your backtrace shows a crash down a code path that only gets executed when an operation is abandoned. None of the steps you've outlined ever cause an abandon or connection close to occur, so again, we can't duplicate the problem. -- -- 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#7025) "the backglue code doesn't install a handler for the Abandon operation"
by hyc＠symas.com 17 Nov '11

17 Nov '11

Marc Patermann wrote: > Howard, > > Howard Chu schrieb (01.11.2011 18:39 Uhr): > >> Also, this script just performs sync searches, what do you use to >> generate the writes? > you mean the write which kills the server? > It just one simple mod of an object which I made in Apache Directory Studio. I'm unable to reproduce this crash. I have your slapd.conf and test data, I have run 80-some instances of your script as you've described. While the initial sync search is running I perform a modify of the base entry of the subordinate database. Everything continues to run. I've also waited for all of the initial refresh traffic to finish first, and then perform the modify, and still no crash. To be more clear - do you perform your modify while the sync searches are still refreshing, or after all of the refreshes have completed? Do you run the clients on the same host as slapd, or on a remote machine? -- -- 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#7090) back-mdb produces wrong slapcat output
by michael＠stroeder.com 16 Nov '11

16 Nov '11

hyc(a)symas.com wrote: > Michael Ströder wrote: >> Howard Chu wrote: >>> What git commit ID? >> >> As said in former times: Before reporting an ITS I *always* do git pull >> checking whether there was something committed after the tested build. If >> there was a new commit I always retest. > > Please just answer the questions. Bear in mind that there is a propagation > delay between the writable git-master and the public mirror. fe1659fc5b01530401174cef3f381ce56918476f Ciao, Michael.

1 0

Re: (ITS#7090) back-mdb produces wrong slapcat output
by hyc＠symas.com 16 Nov '11

16 Nov '11

Michael Ströder wrote: > Howard Chu wrote: >> What git commit ID? > > As said in former times: Before reporting an ITS I *always* do git pull > checking whether there was something committed after the tested build. If > there was a new commit I always retest. Please just answer the questions. Bear in mind that there is a propagation delay between the writable git-master and the public mirror. I always have good reasons for asking for the information that I ask for. Second-guessing me is not going to get problems solved faster. -- -- 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#7085) mutex lockup issue
by hayashis＠indiana.edu 16 Nov '11

16 Nov '11

--0015174c117a5169be04b1e058e5 Content-Type: text/plain; charset=ISO-8859-1 Quanah, We have compiled OpenLDAP 2.4.26 with BDB 5.2.36. The OpenLDAP locked up 4 hours into our testing in similar manner to what I have reported earlier. I believe this issue still occurs on the latest version. However, when I used gdb, I didn't notice the mutex locked threads like I did with OpenLDAP 2.4.22. Following is from locked 2.4.26 slapd server. (gdb) info thread 14 Thread 0x418dd940 (LWP 13814) 0x00000037aa4d48a8 in epoll_wait () from /lib64/libc.so.6 13 Thread 0x420de940 (LWP 13815) 0x00000037aac0aee9 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 12 Thread 0x428df940 (LWP 13816) 0x00000037aac0aee9 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 11 Thread 0x430e0940 (LWP 13843) 0x00000037aac0aee9 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 10 Thread 0x438e1940 (LWP 13855) 0x00000037aac0aee9 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 9 Thread 0x440e2940 (LWP 13856) 0x00000037aac0aee9 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 8 Thread 0x448e3940 (LWP 13857) 0x00000037aac0aee9 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 7 Thread 0x450e4940 (LWP 13858) 0x00000037aac0aee9 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 6 Thread 0x458e5940 (LWP 13859) 0x00000037aac0aee9 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 5 Thread 0x460e6940 (LWP 13860) 0x00000037aac0aee9 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 4 Thread 0x468e7940 (LWP 2007) 0x00000037aac0aee9 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 3 Thread 0x470e8940 (LWP 2008) 0x00000037aa4cd722 in select () from /lib64/libc.so.6 2 Thread 0x478e9940 (LWP 2009) 0x00000037aac0aee9 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 * 1 Thread 0x2ac6ccfdc930 (LWP 13805) 0x00000037aac07b35 in pthread_join () from /lib64/libpthread.so.0 (gdb) thread 3 [Switching to thread 3 (Thread 0x470e8940 (LWP 2008))]#0 0x00000037aa4cd722 in select () from /lib64/libc.so.6 (gdb) bt #0 0x00000037aa4cd722 in select () from /lib64/libc.so.6 #1 0x000000000054ece5 in ?? () #2 0x000000000054aa15 in ?? () #3 0x0000000000557637 in ?? () #4 0x0000000000557c11 in ?? () #5 0x00000000004b2d93 in ?? () #6 0x00000000004e9d7c in ?? () #7 0x00000037aac0673d in start_thread () from /lib64/libpthread.so.0 #8 0x00000037aa4d44bd in clone () from /lib64/libc.so.6 It looks like it's waiting on select() on thread 3 which never get fired when I access it using ldapsearch command. I ran strace on ldapsearch (on a client machine) and following is what I see at the end of the log.. $ strace ldapsearch -h 129.79.14.152 -p 2180 -l 3 -x -b mds-vo-name=WT2,o=grid "(&(objectClass=GlueLocation)(GlueLocationName=TIMESTAMP))" .... write(1, "\n", 1 ) = 1 write(3, "0l\2\1\2cg\4\26mds-vo-name=WT2,o=grid\n"..., 110) = 110 poll([{fd=3, events=POLLIN|POLLPRI|POLLERR|POLLHUP}], 1, -1 Not sure if this strace is useful or not.. but after this, ldapsearch never returned. Thanks, Soichi On Wed, Nov 9, 2011 at 1:13 PM, Quanah Gibson-Mount <quanah(a)zimbra.com>wrote: > --On Wednesday, November 09, 2011 2:01 PM +0000 hayashis(a)indiana.eduwrote: > > 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 > --0015174c117a5169be04b1e058e5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <div>Quanah,</div><div><br></div><div>We have compiled OpenLDAP 2.4.26 with= BDB 5.2.36. The OpenLDAP locked up 4 hours into our testing in similar man= ner to what I have reported earlier. I believe this issue still occurs on t= he latest version.</div> <div><br></div><div>However, when I used gdb, I didn't notice the mutex= locked threads like I did with OpenLDAP 2.4.22.</div><div><br></div><div>F= ollowing is from locked 2.4.26 slapd server.</div><div><br></div><div>(gdb)= info thread</div> <div>=A0 14 Thread 0x418dd940 (LWP 13814) =A00x00000037aa4d48a8 in epoll_wa= it () from /lib64/libc.so.6</div><div>=A0 13 Thread 0x420de940 (LWP 13815) = =A00x00000037aac0aee9 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libp= thread.so.0</div> <div>=A0 12 Thread 0x428df940 (LWP 13816) =A00x00000037aac0aee9 in pthread_= cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0</div><div>=A0 11 Thre= ad 0x430e0940 (LWP 13843) =A00x00000037aac0aee9 in pthread_cond_wait@@GLIBC= _2.3.2 () from /lib64/libpthread.so.0</div> <div>=A0 10 Thread 0x438e1940 (LWP 13855) =A00x00000037aac0aee9 in pthread_= cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0</div><div>=A0 9 Threa= d 0x440e2940 (LWP 13856) =A00x00000037aac0aee9 in pthread_cond_wait@@GLIBC_= 2.3.2 () from /lib64/libpthread.so.0</div> <div>=A0 8 Thread 0x448e3940 (LWP 13857) =A00x00000037aac0aee9 in pthread_c= ond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0</div><div>=A0 7 Thread= 0x450e4940 (LWP 13858) =A00x00000037aac0aee9 in pthread_cond_wait@@GLIBC_2= .3.2 () from /lib64/libpthread.so.0</div> <div>=A0 6 Thread 0x458e5940 (LWP 13859) =A00x00000037aac0aee9 in pthread_c= ond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0</div><div>=A0 5 Thread= 0x460e6940 (LWP 13860) =A00x00000037aac0aee9 in pthread_cond_wait@@GLIBC_2= .3.2 () from /lib64/libpthread.so.0</div> <div>=A0 4 Thread 0x468e7940 (LWP 2007) =A00x00000037aac0aee9 in pthread_co= nd_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0</div><div>=A0 3 Thread = 0x470e8940 (LWP 2008) =A00x00000037aa4cd722 in select () from /lib64/libc.s= o.6</div> <div>=A0 2 Thread 0x478e9940 (LWP 2009) =A00x00000037aac0aee9 in pthread_co= nd_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0</div><div>* 1 Thread 0x= 2ac6ccfdc930 (LWP 13805) =A00x00000037aac07b35 in pthread_join () from /lib= 64/libpthread.so.0</div> <div>(gdb) thread 3</div><div>[Switching to thread 3 (Thread 0x470e8940 (LW= P 2008))]#0 =A00x00000037aa4cd722 in select () from /lib64/libc.so.6</div><= div>(gdb) bt</div><div>#0 =A00x00000037aa4cd722 in select () from /lib64/li= bc.so.6</div> <div>#1 =A00x000000000054ece5 in ?? ()</div><div>#2 =A00x000000000054aa15 i= n ?? ()</div><div>#3 =A00x0000000000557637 in ?? ()</div><div>#4 =A00x00000= 00000557c11 in ?? ()</div><div>#5 =A00x00000000004b2d93 in ?? ()</div><div>= #6 =A00x00000000004e9d7c in ?? ()</div> <div>#7 =A00x00000037aac0673d in start_thread () from /lib64/libpthread.so.= 0</div><div>#8 =A00x00000037aa4d44bd in clone () from /lib64/libc.so.6</div= ><div><br></div><div>It looks like it's waiting on select() on thread 3= which never get fired when I access it using ldapsearch command.=A0</div> <div><br></div><div>I ran strace on ldapsearch (on a client machine) and fo= llowing is what I see at the end of the log..</div><div><br></div><div>$ st= race ldapsearch -h 129.79.14.152 -p 2180 -l 3 -x -b mds-vo-name=3DWT2,o=3Dg= rid "(&(objectClass=3DGlueLocation)(GlueLocationName=3DTIMESTAMP))= "</div> <div><br></div><div>....</div><div>write(1, "\n", 1</div><div>) = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =3D 1</div><div>write(3, "= 0l\2\1\2cg\4\26mds-vo-name=3DWT2,o=3Dgrid\n"..., 110) =3D 110</div><di= v>poll([{fd=3D3, events=3DPOLLIN|POLLPRI|POLLERR|POLLHUP}], 1, -1</div> <div><br></div><div>Not sure if this strace is useful or not.. but after th= is, ldapsearch never returned.</div><div><br></div><div>Thanks,</div><div>S= oichi</div><div><br></div><br><div class=3D"gmail_quote">On Wed, Nov 9, 201= 1 at 1:13 PM, Quanah Gibson-Mount <span dir=3D"ltr"><<a href=3D"mailto:q= uanah(a)zimbra.com">quanah(a)zimbra.com</a>></span> wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex;">--On Wednesday, November 09, 2011 2:01 PM += 0000 <a href=3D"mailto:hayashis@indiana.edu" target=3D"_blank">hayashis@ind= iana.edu</a> wrote:<br> <br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> Full_Name: Soichi Hayashi<br> Version: 2.4.22<br> </blockquote> <br> OpenLDAP 2.4.22 is quite old, and had various known issues. =A0Please use a= current release (2.4.26). =A0This report will not be investigated unless y= ou can reproduce it with a current release of OpenLDAP. =A0You also fail to= note what BDB release you are using, and whether or not it has all the rel= evant patches applied to it. =A0If you have a broken policy of only using v= endor provided packages, then you will need to send a bug report to RedHat,= as it is their job to maintain their vendor packages.<br> <br> <br> Thanks!<span class=3D"HOEnZb"><font color=3D"#888888"><br> <br> --Quanah<br> <br> --<br> <br> Quanah Gibson-Mount<br> Sr. Member of Technical Staff<br> Zimbra, Inc<br> A Division of VMware, Inc.<br> --------------------<br> Zimbra :: =A0the leader in open source messaging and collaboration<br> </font></span></blockquote></div><br> --0015174c117a5169be04b1e058e5--

1 0

(ITS#7091) Limit ppolicy_forward_updates
by michael＠stroeder.com 16 Nov '11

16 Nov '11

Full_Name: Michael Ströder Version: not relevant OS: not relevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (84.163.25.215) This is a feature request: It should be possible to limit effect of ppolicy_forward_updates to certain events like. Maybe just a list of attributes which should be forwarded to a provider. Rationale: To reduce the load on the provide one might want to only forward lockouts to the provider and not each login failure.

1 0

Re: (ITS#7090) back-mdb produces wrong slapcat output
by michael＠stroeder.com 16 Nov '11

16 Nov '11

Howard Chu wrote: > What git commit ID? As said in former times: Before reporting an ITS I *always* do git pull checking whether there was something committed after the tested build. If there was a new commit I always retest. Ciao, Michael.

1 0

Re: (ITS#7090) back-mdb produces wrong slapcat output
by michael＠stroeder.com 16 Nov '11

16 Nov '11

hyc(a)symas.com wrote: >> slapcat with back-mdb mixes entry data in the LDIF output. The entry affected >> had a DN of another entry while retrieving the same entry via LDAP worked >> correctly. I observed this for one entry of several hundred entries. >> >> I currently can't provide test data because this was my private address book >> data. But it was reproducable with slapadd-ed data from an older clean backup >> LDIF file. The last correct backup file I have slapcating with back-mdb is of >> 2011-11-12. I'm building RE24 almost daily from git. Maybe something bad >> happened at that time. >> >> Will try to reproduce with other data but be warned to keep an eye on that. > > What platform, what version, 32 or 64 bit? What git commit ID? openSUSE Linux 11.4 x86_64 > If you revert > the code to an older commit, does it produce the same result? I know that such a report is not sufficient for you to start fixing it. But sometimes it's not possible to report it more precisely. As said I will try to reproduce with non-private data. It was too late to do more testing yesterday. > I've slapcat'd a 5 million entry back-hdb database and loaded it into > back-mdb. Then slapcat'd that result; it is exactly identical to the original. > Using both RE24 pulled a couple minutes ago, and git master built November > 1st. There have been no functional changes to the code in a while, purely > cosmetic changes. Maybe it's dependent on the sort of data? The errornous entry contains attribute jpegPhoto of size 7317 bytes. Ciao, Michael.

1 0

Re: (ITS#7090) back-mdb produces wrong slapcat output
by hyc＠symas.com 15 Nov '11

15 Nov '11

michael(a)stroeder.com wrote: > Full_Name: Michael Ströder > Version: RE24 pulled from git > OS: > URL: > Submission from: (NULL) (84.163.26.40) > > > slapcat with back-mdb mixes entry data in the LDIF output. The entry affected > had a DN of another entry while retrieving the same entry via LDAP worked > correctly. I observed this for one entry of several hundred entries. > > I currently can't provide test data because this was my private address book > data. But it was reproducable with slapadd-ed data from an older clean backup > LDIF file. The last correct backup file I have slapcating with back-mdb is of > 2011-11-12. I'm building RE24 almost daily from git. Maybe something bad > happened at that time. > > Will try to reproduce with other data but be warned to keep an eye on that. What platform, what version, 32 or 64 bit? What git commit ID? If you revert the code to an older commit, does it produce the same result? I've slapcat'd a 5 million entry back-hdb database and loaded it into back-mdb. Then slapcat'd that result; it is exactly identical to the original. Using both RE24 pulled a couple minutes ago, and git master built November 1st. There have been no functional changes to the code in a while, purely cosmetic changes. -- -- 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

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