- openldap-bugs - openldap.org

Re: (ITS#6163) back-sql DoS when searching for empty attr
by stephane.chazelas＠seebyte.com 30 Jun '09

30 Jun '09

Hiya, see also https://bugs.launchpad.net/bugs/382677 Whole text included here: When using the SQL backend, a search like: ldapsearch ... '(cn=)' causes slapd to crash with this error: slapd: /tmp/openldap-2.4.15/servers/slapd/back-sql/search.c:1366: backsql_process_filter_attr: Assertion `0' failed. Looking at the code there, it does a switch(f->f_choice) { .... default: assert(0); } As it happens, in that instance f_choice is something like 0x80a3, that is SLAPD_FILTER_UNDEFINED|LDAP_FILTER_EQUALITY. And the back-sql backend doesn't support that SLAPD_FILTER_UNDEFINED flag like the other backends, hence the abort() on that assert. A work around for that (change in indentation not shown): --- search.c~ 2009-06-01 15:55:16.000000000 +0100 +++ servers/slapd/back-sql/search.c 2009-06-01 17:00:51.000000000 +0100 @@ -717,6 +717,9 @@ goto done; } + if (f->f_choice & SLAPD_FILTER_UNDEFINED) { + rc = -1; + } else { switch( f->f_choice ) { case LDAP_FILTER_OR: rc = backsql_process_filter_list( bsi, f->f_or, @@ -772,6 +775,7 @@ ad = f->f_av_desc; break; } + } if ( rc == -1 ) { goto done; That's only a work around. The fix would be to implement the support for such searches. Best regards, Stephane

1 0

Re: (ITS#6186) sizelimit broken
by h.b.furuseth＠usit.uio.no 29 Jun '09

29 Jun '09

Christian.Fischer(a)fischundfischer.com writes: > Args debugging showed me ors_slimit of 500 in all cases > (servers/slapd/search.c:do_search():123) Note that at this point the fields have just been parsed from the protocol message. So that's the limit as it was sent by the client. (From SIZELIMIT in ldap.conf, maybe?) If the client sends 500, limits_check() should not reset it. -- Hallvard

1 0

Re: (ITS#6186) sizelimit broken
by Christian.Fischer＠fischundfischer.com 29 Jun '09

29 Jun '09

On Monday 29 June 2009, Howard Chu wrote: > Unfortunately not. I was also unable to reproduce this behavior on 2.4.16 > or on current code. Without a clear way to illustrate the problem, we have > nothing to investigate. Yes, I understand this. > Likewise, since you mention that you're running > "patched slapd" we can't help you with that either. The patch sets ors_slimit = 0, nothing else. This is only FYI if someone runs into the same problem. Christian

1 0

Re: (ITS#6186) sizelimit broken
by hyc＠symas.com 29 Jun '09

29 Jun '09

Christian Fischer wrote: > On Wednesday 24 June 2009, Howard Chu wrote: > >> Your explanation is a bit unclear. Please provide an ldapsearch commandline >> that demonstrates the problem with the slapd.conf you provided. >> >> When a given sizelimit is configured on the server, what values of >> sizelimit requested by the client are working correctly or incorrectly? > > Due to all servers run a patched slapd and all are in productive state i've > set up 2 testsystems (provider - consumer). > > I can't reproduce the buggy behavior. > > Let me explain what i have done before submitting the bug report. > > I've set up two slapd in mirrormode and one as proxy and some customer slapd, > all unpatched. After working around ITS#6167 I've initiated the initial > customer replication with the proxy as peer and got a sizelimit of 500. I've > tried replication against one mirror, that failed with sizelimit 500. The > providers sizelimit was set to unlimited. > > I've tried replication with different sizelimit values, 10 gave me 10 entries > back, 500 gave me 500 back, 502 gave me 500 and -1 gave me 500 back. > > Args debugging showed me ors_slimit of 500 in all cases > (servers/slapd/search.c:do_search():123) > > Hope that helps Unfortunately not. I was also unable to reproduce this behavior on 2.4.16 or on current code. Without a clear way to illustrate the problem, we have nothing to investigate. Likewise, since you mention that you're running "patched slapd" we can't help you with that either. -- -- 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#6186) sizelimit broken
by Christian.Fischer＠fischundfischer.com 29 Jun '09

29 Jun '09

On Wednesday 24 June 2009, Howard Chu wrote: > Your explanation is a bit unclear. Please provide an ldapsearch commandline > that demonstrates the problem with the slapd.conf you provided. > > When a given sizelimit is configured on the server, what values of > sizelimit requested by the client are working correctly or incorrectly? Due to all servers run a patched slapd and all are in productive state i've set up 2 testsystems (provider - consumer). I can't reproduce the buggy behavior. Let me explain what i have done before submitting the bug report. I've set up two slapd in mirrormode and one as proxy and some customer slapd, all unpatched. After working around ITS#6167 I've initiated the initial customer replication with the proxy as peer and got a sizelimit of 500. I've tried replication against one mirror, that failed with sizelimit 500. The providers sizelimit was set to unlimited. I've tried replication with different sizelimit values, 10 gave me 10 entries back, 500 gave me 500 back, 502 gave me 500 and -1 gave me 500 back. Args debugging showed me ors_slimit of 500 in all cases (servers/slapd/search.c:do_search():123) Hope that helps Christian

1 0

Re: (ITS#5836) hung writers
by jorge.perez＠adaptia.net 29 Jun '09

29 Jun '09

--001636c5b621da4708046d784a4e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Hello, I still reproduce this problem with 2.4.17-prerelease. I have a client that request a lof of operations at the same time through a connection. The slapd seems to overload and finally close the connection sending a reset to the client and when this happens the connection hungs eating the CPU, blocked in the pthread_cond_wait in send_ldap_ber function at the same point of the first trace sent in this report. Best regards --001636c5b621da4708046d784a4e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hello, I still reproduce this problem with 2.4.17-prerelease. I have= a client that request a lof of operations at the same time through a conne= ction. The slapd seems to overload and finally close the connection sending= a reset to the client and when this happens the connection hungs eating th= e CPU, blocked in the pthread_cond_wait in send_ldap_ber function at the sa= me point of the first trace sent in this report. Best regards --001636c5b621da4708046d784a4e--

1 0

Re: (ITS#6189) test056 failure
by hyc＠symas.com 28 Jun '09

28 Jun '09

hyc(a)OpenLDAP.org wrote: > Full_Name: Howard Chu > Version: RE24/HEAD > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (76.91.220.157) > Submitted by: hyc > > > See http://www.openldap.org/lists/openldap-devel/200906/msg00048.html > > Note that the proposed fix may mean revisiting ITS#3850. > Without the patch in HEAD, test056 failed after 21 iterations on my OpenSUSE system. With the patch it ran 1000 iterations successfully. -- -- 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#6189) test056 failure
by hyc＠OpenLDAP.org 28 Jun '09

28 Jun '09

Full_Name: Howard Chu Version: RE24/HEAD OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (76.91.220.157) Submitted by: hyc See http://www.openldap.org/lists/openldap-devel/200906/msg00048.html Note that the proposed fix may mean revisiting ITS#3850.

1 0

potential bug
by Rahul Amaram 26 Jun '09

26 Jun '09

Hi, While working with OpenLDAP, I've observed something strange. I am not sure if this is the anticipated behaviour. Let us say we have two attributes 'name' and 'middleName' and the former is the superior of the latter i.e. attributetype ( 1.3.6.1.4.74 NAME 'middleName' SUP name ) Now let us assume that the value of the attribute 'middleName' for a particular dn is 'Konda'. Then performing a search on the basedn with the filter "(name=Konda)" returns that particular dn. Is this a bug or anticipated behaviour? Regards, Rahul.

3 3

Re: (ITS#6185) test033-glue-syncrepl failed
by hyc＠symas.com 26 Jun '09

26 Jun '09

richton(a)nbcs.rutgers.edu wrote: > slapd-glue-syncrepl1.conf 1.17 > slapd-glue-syncrepl2.conf 1.17 > > has tested well for about twelve hours of continuous loop. I think this is > good now. Great, thanks for the confirmation. -- -- 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#6185) test033-glue-syncrepl failed
by richton＠nbcs.rutgers.edu 26 Jun '09

26 Jun '09

slapd-glue-syncrepl1.conf 1.17 slapd-glue-syncrepl2.conf 1.17 has tested well for about twelve hours of continuous loop. I think this is good now.

1 0

Re: (ITS#6185) test033-glue-syncrepl failed
by richton＠nbcs.rutgers.edu 25 Jun '09

25 Jun '09

The question came up if this was new post-2.4.16. I recompiled 2.4.16 and ran test033 for 30 hours with no failures. I've now switched back to HEAD, and I found first failure in a bit under three hours. (Note that when I found this, I was running all tests, not only 033. With 2.4.16 and today's HEAD run, I'm looping test033 only, because at this point it's the only place I'm seeing failures.)

1 0

(ITS#6188) ldap_pvt_thread_pool_retract needs a stub
by richton＠nbcs.rutgers.edu 25 Jun '09

25 Jun '09

Full_Name: Aaron Richton Version: HEAD OS: irrelevant URL: Submission from: (NULL) (128.6.31.135) to allow --without-threads to link. I, Aaron Richton, hereby place the following modifications to OpenLDAP Software (and only these modifications) into the public domain. Hence, these modifications may be freely used and/or redistributed for any purpose with or without attribution and/or other notice. --- thr_stub.c~ 2009-06-25 14:04:22.000000000 -0400 +++ thr_stub.c 2009-06-25 14:14:39.000000000 -0400 @@ -167,6 +167,14 @@ } int +ldap_pvt_thread_pool_retract ( + ldap_pvt_thread_pool_t *tpool, + ldap_pvt_thread_start_t *start_routine, void *arg ) +{ + return(0); +} + +int ldap_pvt_thread_pool_maxthreads ( ldap_pvt_thread_pool_t *tpool, int max_threads ) { return(0);

1 0

(ITS#6187) release page update
by quanah＠OpenLDAP.org 25 Jun '09

25 Jun '09

Full_Name: Quanah Gibson-Mount Version: NA OS: NA URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.111.29.239) This page: http://www.openldap.org/software/roadmap.html needs updating. 2.3 is no longer a current release.

1 0

Re: (ITS#5535) smbk5pwd uses private heimdal functions
by Guillaume.Rousse＠inria.fr 24 Jun '09

24 Jun '09

The patch is course usable for integration in openldap (I originaly posted it on the list precisely for this purpose, sorry if I wasn't clear enough).

1 0

(ITS#6174) Backtrace for a segfault
by frank.offermanns＠caseris.de 24 Jun '09

24 Jun '09

Dies ist eine mehrteilige Nachricht im MIME-Format. --=_alternative 002BEC64C12575DF_= Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Hello, for this test setup i got an empty database and tried to add 20000 Users=20 under o=3Dcaesar,ou=3DUsers,o=3Dtestcas at server1 (windos vista) while try= ing=20 to add 20000 Users under o=3Dcaesar,ou=3DUsers,o=3Dtestxp at server2 (Windo= ws=20 XP). The slapd.exe on the XP Server crashed. Compiled the version from=20 HEAD with Mingw/MSYS for windows. The servers are configured as stated in my previos post (multimaster). Here comes the backtrace of the segfault: I am new to gdb debbuging to please feel free to tell me if you need=20 addtional info (it would be nice if you would tell me the commands to do=20 so). Starting program: C:\all/slapd.exe -F slapd.d [New thread 2580.0x36c] [New thread 2580.0x550] [New thread 2580.0xbfc] [New thread 2580.0xad8] [New thread 2580.0x714] [New thread 2580.0xe90] [New thread 2580.0xcec] [New thread 2580.0x37c] [New thread 2580.0x108] [New thread 2580.0x1a8] [New thread 2580.0x1dc] [New thread 2580.0xd28] [New thread 2580.0x564] [New thread 2580.0xf50] [New thread 2580.0x29c] [New thread 2580.0xfdc] Program received signal SIGSEGV, Segmentation fault. [Switching to thread 2580.0xe90] 0x004cd88f in syncprov=5Fop=5Fmod (op=3D0xd8e5e38, rs=3D0x4adfce8) at=20 syncprov.c:1970 1970 for ( m2 =3D mt->mt=5Fmods;= =20 m2->mi=5Fn ext !=3D mi; (gdb) bt #0 0x004cd88f in syncprov=5Fop=5Fmod (op=3D0xd8e5e38, rs=3D0x4adfce8) at syncprov.c:1970 #1 0x0048994a in overlay=5Fop=5Fwalk (op=3D0xd8e5e38, rs=3D0x4adfce8, which=3Dop=5Fmodify, oi=3D0xffbe70, on=3D0xf82df0) at backover.c:659 #2 0x00489b74 in over=5Fop=5Ffunc (op=3D0xd8e5e38, rs=3D0x4adfce8,=20 which=3Dop=5Fmodify) at backover.c:721 #3 0x00489c49 in over=5Fop=5Fmodify (op=3D0xd8e5e38, rs=3D0x4adfce8) at backover.c:755 #4 0x004355c1 in fe=5Fop=5Fmodify (op=3D0xd8e5e38, rs=3D0x4adfce8) at=20 modify.c:301 #5 0x0043508f in do=5Fmodify (op=3D0xd8e5e38, rs=3D0x4adfce8) at modify.c:= 175 #6 0x0041c8f0 in connection=5Foperation (ctx=3D0x4adfdd8, arg=5Fv=3D0xd8e5= e38) at connection.c:1115 #7 0x0041cdb6 in connection=5Fread=5Fthread (ctx=3D0x4adfdd8, argv=3D0x7) at connection.c:1248 #8 0x00504621 in ldap=5Fint=5Fthread=5Fpool=5Fwrapper () #9 0x77c0a3b0 in msvcrt!=5Fendthreadex () from=20 C:\WINDOWS\system32\msvcrt.dll #10 0x7c80b699 in KERNEL32!GetModuleFileNameA () from C:\WINDOWS\system32\kernel32.dll #11 0x00000000 in ?? () Best regards, Frank Offermanns - Frank Offermanns | Entwicklung | CASERIS GmbH=20 Fon: +49 2402 7654-566 Fax: +49 2402 7654-8566 | E-Mail: Frank.Offermanns(a)caseris.com=20 -- CASERIS GmbH | Am Birkenfeld 1-3 | D-52222 Stolberg Gesch=E4ftsf=FChrer Dipl.-Ing. Stefan Preu=DF | Registergericht: Amtsgerich= t=20 Aachen, HRB 14758 --=_alternative 002BEC64C12575DF_= Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Hello, for this test setup i got an empty d= atabase and tried to add 20000 Users under o=3Dcaesar,ou=3DUsers,o=3Dtestcas at ser= ver1 (windos vista) while trying to add 20000 Users under o=3Dcaesar,ou=3DUsers,= o=3Dtestxp at server2 (Windows XP). The slapd.exe on the XP Server crashed. Compiled the version from HEAD with Mingw/MSYS for windows. The servers are configured as stated in my previos post (multimaster). Here comes the backtrace of the segf= ault: I am new to gdb debbuging to please feel free to tell me if you need addtional info (it would be nice if you would tell me the commands to do so). Starting program: C:\all/slapd.exe -F slapd.d [New thread 2580.0x36c] [New thread 2580.0x550] [New thread 2580.0xbfc] [New thread 2580.0xad8] [New thread 2580.0x714] [New thread 2580.0xe90] [New thread 2580.0xcec] [New thread 2580.0x37c] [New thread 2580.0x108] [New thread 2580.0x1a8] [New thread 2580.0x1dc] [New thread 2580.0xd28] [New thread 2580.0x564] [New thread 2580.0xf50] [New thread 2580.0x29c] [New thread 2580.0xfdc] Program received signal SIGSEGV, Seg= mentation fault. [Switching to thread 2580.0xe90]</fo= nt> 0x004cd88f in syncprov=5Fop=5Fmod (o= p=3D0xd8e5e38, rs=3D0x4adfce8) at syncprov.c:1970 1970         &nb= sp;                                  for ( m2 =3D mt->mt=5Fmods; m2-= >mi=5Fn ext !=3D mi; (gdb) bt #0  0x004cd88f in syncprov=5Fop= =5Fmod (op=3D0xd8e5e38, rs=3D0x4adfce8)     at syncprov.c:1970</fo= nt> #1  0x0048994a in overlay=5Fop= =5Fwalk (op=3D0xd8e5e38, rs=3D0x4adfce8,     which=3Dop=5Fmodify, o= i=3D0xffbe70, on=3D0xf82df0) at backover.c:659 #2  0x00489b74 in over=5Fop=5Ff= unc (op=3D0xd8e5e38, rs=3D0x4adfce8, which=3Dop=5Fmodify)     at backover.c:721</fon= t> #3  0x00489c49 in over=5Fop=5Fm= odify (op=3D0xd8e5e38, rs=3D0x4adfce8)     at backover.c:755</fon= t> #4  0x004355c1 in fe=5Fop=5Fmod= ify (op=3D0xd8e5e38, rs=3D0x4adfce8) at modify.c:301 #5  0x0043508f in do=5Fmodify (= op=3D0xd8e5e38, rs=3D0x4adfce8) at modify.c:175 #6  0x0041c8f0 in connection=5F= operation (ctx=3D0x4adfdd8, arg=5Fv=3D0xd8e5e38)     at connection.c:1115</= font> #7  0x0041cdb6 in connection=5F= read=5Fthread (ctx=3D0x4adfdd8, argv=3D0x7)     at connection.c:1248</= font> #8  0x00504621 in ldap=5Fint=5F= thread=5Fpool=5Fwrapper () #9  0x77c0a3b0 in msvcrt!=5Fend= threadex () from C:\WINDOWS\system32\msvcrt.dll #10 0x7c80b699 in KERNEL32!GetModule= FileNameA ()    from C:\WINDOWS\system3= 2\kernel32.dll #11 0x00000000 in ?? () Best regards, Frank Offermanns - Frank Offermanns | Entw= icklung | <a href=3Dhttp://www.caseris.de/>CASERIS GmbH</a> Fon: +49 2402 7654-566<= /font> Fax: +49 2402 7654-8566= | E-Mail: <a href=3Dmailto:Frank.Offermanns@caseris.com>Frank.Offermanns(a)caseris.com</= a> -- CASERIS GmbH | Am Birke= nfeld 1-3 | D-52222 Stolberg Gesch=E4ftsf=FChrer Dip= l.-Ing. Stefan Preu=DF | Registergericht: Amtsgericht Aachen, HRB 14758 --=_alternative 002BEC64C12575DF_=--

1 0

Re: (ITS#5535) smbk5pwd uses private heimdal functions
by admin＠dmarkey.com 24 Jun '09

24 Jun '09

--001485f1e78e38f960046d0c351a Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Please note Guillaume.Rousse(a)inria.fr is the author of the patch i supplied. Origin: http://www.stacken.kth.se/lists/heimdal-discuss/2008-05/msg00107.html --001485f1e78e38f960046d0c351a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Please note <a href=3D"mailto:Guillaume.Rousse@inria.fr">Guillaume.Rousse@i= nria.fr</a> =A0is the author of the patch i supplied. Origin: <a href=3D"http://www.sta= cken.kth.se/lists/heimdal-discuss/2008-05/msg00107.html">http://www.stacken= .kth.se/lists/heimdal-discuss/2008-05/msg00107.html</a> --001485f1e78e38f960046d0c351a--

1 0

Re: (ITS#6186) sizelimit broken
by hyc＠symas.com 24 Jun '09

24 Jun '09

christian.fischer(a)fischundfischer.com wrote: > Full_Name: Christian Fischer > Version: 2.4.16 > OS: gentoo amd64 > URL: > Submission from: (NULL) (213.221.82.34) > > > slapd ignores sizelimit values above 500 and -1 (unlimited) > > If sizelimit is set to a value>=0 and<=500 the behavior is as expected, > unlimited > (-1) and values>500 are ignored. > > I've turned on args debugging to see if something is different between 2.4.16 > and 2.3.43, which works for me. > > Version 2.3.43 op->ors_slimit is set to 0 if do_search() is executed, > version 2.4.16 op->ors_slimit is set to 500 (SLAPD_DEFAULT_SIZELIMIT). > > That explains the different behavior of limits_check(). > > With ors_slimit set to SLAPD_DEFAULT_SIZELIMIT it runs into > servers/slapd/limits.c:1294 and ors_slimit will only set to > ors_limit->lms_s_soft if the value of ors_limit->lms_s_soft is between 1 and > SLAPD_DEFAULT_SIZELIMIT -1. Your explanation is a bit unclear. Please provide an ldapsearch commandline that demonstrates the problem with the slapd.conf you provided. When a given sizelimit is configured on the server, what values of sizelimit requested by the client are working correctly or incorrectly? -- -- 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#5701) connection.c asserting during test008
by richton＠nbcs.rutgers.edu 23 Jun '09

23 Jun '09

The only connection issue I'm still seeing is #5733...I believe this is resolved in modern code.

1 0

(ITS#6186) sizelimit broken
by christian.fischer＠fischundfischer.com 23 Jun '09

23 Jun '09

Full_Name: Christian Fischer Version: 2.4.16 OS: gentoo amd64 URL: Submission from: (NULL) (213.221.82.34) slapd ignores sizelimit values above 500 and -1 (unlimited) If sizelimit is set to a value >=0 and <=500 the behavior is as expected, unlimited (-1) and values >500 are ignored. I've turned on args debugging to see if something is different between 2.4.16 and 2.3.43, which works for me. Version 2.3.43 op->ors_slimit is set to 0 if do_search() is executed, version 2.4.16 op->ors_slimit is set to 500 (SLAPD_DEFAULT_SIZELIMIT). That explains the different behavior of limits_check(). With ors_slimit set to SLAPD_DEFAULT_SIZELIMIT it runs into servers/slapd/limits.c:1294 and ors_slimit will only set to ors_limit->lms_s_soft if the value of ors_limit->lms_s_soft is between 1 and SLAPD_DEFAULT_SIZELIMIT -1. This patch has solved my problem for now, sizelimit statement is working without restrictions. --- openldap-2.4.16/servers/slapd_orig/limits.c 2009-01-22 01:01:01.000000000 +0100 +++ openldap-2.4.16/servers/slapd/limits.c 2009-06-15 09:27:36.212817654 +0200 @@ -1077,6 +1077,9 @@ return 0; } + /* fix sizelimit */ + op->ors_slimit = 0; + /* allow root to set no limit */ if ( be_isroot( op ) ) { op->ors_limit = NULL; ### config snippet ### include /etc/openldap/schema/core.schema include /etc/openldap/schema/cosine.schema include /etc/openldap/schema/inetorgperson.schema include /etc/openldap/schema/rfc2307bis.schema include /etc/openldap/schema/samba.schema include /etc/openldap/schema/misc.schema include /etc/openldap/schema/openssh-lpk.schema include /etc/openldap/schema/radius.schema include /etc/openldap/schema/egr.schema include /etc/openldap/schema/mozillaabpersonalpha.schema include /etc/openldap/schema/dhcp.schema pidfile /var/run/openldap/slapd.pid argsfile /var/run/openldap/slapd.args TLSCertificateFile /etc/openldap/ssl/ldap.pem TLSCertificateKeyFile /etc/openldap/ssl/ldap.pem TLSCACertificateFile /etc/openldap/ssl/ca.crt TLSVerifyClient never loglevel none serverID 2 security ssf=256 disallow bind_anon require authc database bdb suffix "dc=foo,dc=bar" rootdn "cn=Manager,dc=foo,dc=bar" rootpw secret directory /var/lib/openldap-data checkpoint 32 30 sizelimit unlimited index objectclass,entryCSN,entryUUID eq overlay syncprov syncprov-checkpoint 100 10 syncprov-sessionlog 100 syncprov-reloadhint TRUE syncrepl rid=123 provider=ldap://isc01.foo.bar starttls=yes tls_reqcert=never type=refreshAndPersist retry="5 5 60 +" searchbase="dc=foo,dc=bar" scope=sub schemachecking=on bindmethod=simple binddn="cn=syncrepl,ou=dsa,dc=foo,dc=bar" credentials=secret mirrormode on ### ACL ### # [snip]

1 0

Re: (ITS#6185) test033-glue-syncrepl failed
by richton＠nbcs.rutgers.edu 23 Jun '09

23 Jun '09

This appears to be semi-regular; I have two more substantially identical testrun directories indicating failure.

1 0

Re: ITS#6101 Uninitialized SlapReply components
by h.b.furuseth＠usit.uio.no 23 Jun '09

23 Jun '09

hyc(a)symas.com writes: > What do you mean by "components are commonly used uninitialized" ? > Have you actually seen cases where the code reads these values before > they are init'd? Certainly valgrind never trips over them. There is nothing for Valgrind to trip over if the compiler zero-fills rs.sr_un union when it sees SlapReply rs = {REP_RESULT}; However, add this in slap.h, which is all the compiler needs to emit for that initialization: #define DECL_SlapReply(name, type) \ SlapReply name; \ name.sr_type = 0; \ name.sr_tag = 0; \ name.sr_msgid = 0; \ name.sr_err = 0; \ name.sr_matched = 0;\ name.sr_text = 0; \ name.sr_ref = 0; \ name.sr_ctrls = 0; \ name.sr_un.sru_sasl.r_sasldata = 0; \ name.sr_flags = 0 Replace current initializations with that as follows: grep -l 'SlapReply[<tab> ][a-z0-9]* *=' *.c */*.c | xargs perl -i -pe ' s/^(\t+)(SlapReply)\s+(\w+)\s*=\s*{\s*(\w+)\s*}\;/$1DECL_$2($3, $4)\;/' (type ctrl-v tab in shell for the<tab>) Compile with C99 or gcc extension mode to allow mixed code and decls. make test doesn't even survive test000. And yes, valgrind is annoyed. -- Hallvard

1 0

Re: (ITS#6184) slapd segmentation fault
by michael＠stroeder.com 23 Jun '09

23 Jun '09

jginsberg(a)thehive.com wrote: > > I'm not sure I'm really comfortable with running a pre-release 2.4.16 is the currently STABLE release. You should definitely use that instead of 2.4.15. See also: http://www.openldap.org/faq/data/cache/225.html Ciao, Michael.

1 0

ITS#6101 Uninitialized SlapReply components
by hyc＠symas.com 23 Jun '09

23 Jun '09

What do you mean by "components are commonly used uninitialized" ? Have you actually seen cases where the code reads these values before they are init'd? Certainly valgrind never trips over them. -- -- 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#6170) test039 seg faults
by hyc＠symas.com 23 Jun '09

23 Jun '09

michael(a)stroeder.com wrote: > Seg faulted again. > > Take two of tests/testrun/ available under: > > http://www.stroeder.com/temp/openldap/its6170_test039-testrun2.tar.gz > > I really wonder why I have such subtle issues which are not > deterministic. Maybe it's because I'm running make test on an old laptop > with Pentium Mobile 1,8 GHz which is rather slow? > > I tested with default values SLEEP1=7 and SLEEP2=15. Even if these > values are too low for this particular system slapd should never ever > seg fault. Same trace as #5733, closing this ITS as a dup. -- -- 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#6174) Permanent high CPU Load with Multimaster
by hyc＠symas.com 23 Jun '09

23 Jun '09

Frank.Offermanns(a)caseris.de wrote: > Full_Name: Frank Offermanns > Version: 2.4.16 > OS: Windows XP/Ubuntu 9.04 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (217.6.189.242) > > > Hello everyone, > > I compiled the LDAP Version 2.4.16 from CVS at 16 June with MINGW/MSYS on > Windows. I used the latest version because every previous 2.4.16 version had > similar problems. There is no "latest 2.4.16" version. There is only one release with version number 2.4.16, whether you got it from CVS or from the web site. > I have two systems working together as multimasters. After a random time (less > than a day) it can happen, that a core of a CPU uses 100 % CPU Load. Both System > seems to be working correctly, but the High CPU Load slows down everything. > No matter how long i wait, this core stays at 100 % CPU load. > On another test a test write operation never returned and I also had the high > CPU load. After i killed my test write process, the slapd.exe crashed. (The > write procees was on a another PC) Use gdb to get traces of the active threads when the 100% CPU situation occurs. Likewise, use gdb to get traces when slapd crashes. -- -- 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#6184) slapd segmentation fault
by jginsberg＠thehive.com 23 Jun '09

23 Jun '09

Hi Quanah -- I'm not sure I'm really comfortable with running a pre-release -- this is for our corporate identity and contact management server, and it is as mission critical as that sounds. It was enough of a headache running it under production load inside gdb to get the stack trace. :-) The workaround we've employed for the timebeing is switching to the bdb backend and using monit to keep an eye on things. We'll look forward to seeing what comes out in 2.4.17 and re-evaluate then. Thanks! -jag On Jun 22, 2009, at 5:31 PM, Quanah Gibson-Mount wrote: > --On Monday, June 22, 2009 4:08 PM +0000 jginsberg(a)hostyours.com > wrote: > >> Full_Name: Joshua Ginsberg >> Version: 2.4.15 >> OS: Debian lenny 2.6.29.4 >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (208.78.90.5) > > There have been numerous fixes since 2.4.15 and 2.4.16. I suggest > you try the current CVS RE24 and see if you still have issues. > > --Quanah > > -- > > Quanah Gibson-Mount > Principal Software Engineer > Zimbra, Inc > -------------------- > Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6184) slapd segmentation fault
by quanah＠zimbra.com 22 Jun '09

22 Jun '09

--On Monday, June 22, 2009 4:08 PM +0000 jginsberg(a)hostyours.com wrote: > Full_Name: Joshua Ginsberg > Version: 2.4.15 > OS: Debian lenny 2.6.29.4 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (208.78.90.5) There have been numerous fixes since 2.4.15 and 2.4.16. I suggest you try the current CVS RE24 and see if you still have issues. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#6185) test033-glue-syncrepl failed
by richton＠nbcs.rutgers.edu 22 Jun '09

22 Jun '09

Full_Name: Aaron Richton Version: HEAD OS: Solaris 9 URL: https://www.nbcs.rutgers.edu/~richton/test033-testrun-200906221036.tar.gz Submission from: (NULL) (74.105.10.5) test033 *.flt differ. No seg fault/assertions, just unexpected results. testrun directory (includes -d -1) is in the linked tarball.

1 0

Re: (ITS#6184) slapd segmentation fault
by jginsberg＠thehive.com 22 Jun '09

22 Jun '09

To elaborate on our setup... We're running 2.4.15 compiled with openssl using two servers in syncrepl mirrormode using cn=config style configuration and the hdb backend. The OS is debian lenny, so we're using Debian's bdb version 4.6 package. Our server segfaults quite regularly under moderate production load -- because of the number of diverse users accessing the directory over numerous systems, I cannot identify a single trigger that causes the segmentation fault. -jag

1 0

(ITS#6184) slapd segmentation fault
by jginsberg＠hostyours.com 22 Jun '09

22 Jun '09

Full_Name: Joshua Ginsberg Version: 2.4.15 OS: Debian lenny 2.6.29.4 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (208.78.90.5) Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x472a7950 (LWP 3520)] 0x00007f7a8e7d44aa in pthread_mutex_lock () from /lib/libpthread.so.0 (gdb) thread apply all bt Thread 15 (Thread 0x472a7950 (LWP 3520)): #0 0x00007f7a8e7d44aa in pthread_mutex_lock () from /lib/libpthread.so.0 #1 0x00007f7a8c3c7741 in bdb_cache_delete_internal (cache=0x8429f0, e=0x7f7a880dff90, decr=0) at cache.c:1335 #2 0x00007f7a8c3c820b in hdb_cache_lru_purge (bdb=0x842990) at cache.c:749 #3 0x00007f7a8c3c8c6a in hdb_cache_find_id (op=0x7f7a8811bbe0, tid=0x7f7a88104820, id=2211, eip=<value optimized out>, flag=0, lock=0x472a5790) at cache.c:1016 #4 0x00007f7a8c3b9e79 in hdb_search (op=0x7f7a8811bbe0, rs=0x472a6ca0) at search.c:229 #5 0x00000000004962d7 in overlay_op_walk (op=0x7f7a8811bbe0, rs=0x472a6ca0, which=op_search, oi=0x842da0, on=0x0) at /usr/src/openldap_2.4.15.orig/servers/slapd/backover.c:669 #6 0x0000000000496d53 in over_op_func (op=0x7f7a8811bbe0, rs=0xd7510, which=op_bind) at /usr/src/openldap_2.4.15.orig/servers/slapd/backover.c:721 #7 0x0000000000434811 in fe_op_search (op=0x7f7a8811bbe0, rs=0x472a6ca0) at /usr/src/openldap_2.4.15.orig/servers/slapd/search.c:366 #8 0x000000000043500c in do_search (op=0x7f7a8811bbe0, rs=0x472a6ca0) at /usr/src/openldap_2.4.15.orig/servers/slapd/search.c:217 #9 0x0000000000432666 in connection_operation (ctx=0x472a6e00, arg_v=<value optimized out>) at /usr/src/openldap_2.4.15.orig/servers/slapd/connection.c:1097 #10 0x000000000043315d in connection_read_thread (ctx=0x472a6e00, argv=<value optimized out>) at /usr/src/openldap_2.4.15.orig/servers/slapd/connection.c:1223 #11 0x00007f7a9042314a in ldap_int_thread_pool_wrapper ( xpool=<value optimized out>) at /usr/src/openldap_2.4.15.orig/libraries/libldap_r/tpool.c:663 #12 0x00007f7a8e7d2fc7 in start_thread () from /lib/libpthread.so.0 #13 0x00007f7a8e5485ad in clone () from /lib/libc.so.6 #14 0x0000000000000000 in ?? () Thread 14 (Thread 0x46aa6950 (LWP 3519)): #0 0x00007f7a8e7d6d29 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 #1 0x00007f7a9042319d in ldap_int_thread_pool_wrapper ( xpool=<value optimized out>) at /usr/src/openldap_2.4.15.orig/libraries/libldap_r/tpool.c:654 #2 0x00007f7a8e7d2fc7 in start_thread () from /lib/libpthread.so.0 #3 0x00007f7a8e5485ad in clone () from /lib/libc.so.6 #4 0x0000000000000000 in ?? () Thread 13 (Thread 0x462a5950 (LWP 3518)): #0 0x00007f7a8e7d6d29 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 ---Type <return> to continue, or q <return> to quit--- #1 0x00007f7a9042319d in ldap_int_thread_pool_wrapper ( xpool=<value optimized out>) at /usr/src/openldap_2.4.15.orig/libraries/libldap_r/tpool.c:654 #2 0x00007f7a8e7d2fc7 in start_thread () from /lib/libpthread.so.0 #3 0x00007f7a8e5485ad in clone () from /lib/libc.so.6 #4 0x0000000000000000 in ?? () Thread 12 (Thread 0x45aa4950 (LWP 3517)): #0 0x00007f7a8e7d9384 in __lll_lock_wait () from /lib/libpthread.so.0 #1 0x00007f7a8e7d4bf0 in _L_lock_102 () from /lib/libpthread.so.0 #2 0x00007f7a8e7d44fe in pthread_mutex_lock () from /lib/libpthread.so.0 #3 0x00007f7a8c3c73cf in bdb_cache_lru_link (bdb=0x842990, ei=0x80) at cache.c:127 #4 0x00007f7a8c3c8da4 in hdb_cache_find_id (op=0x7f7a88134720, tid=0x7f7a8811f780, id=3568, eip=0x45aa2968, flag=2, lock=0x45aa28f0) at cache.c:935 #5 0x00007f7a8c3baa1c in hdb_search (op=0x7f7a88134720, rs=0x45aa3ca0) at search.c:705 #6 0x00000000004962d7 in overlay_op_walk (op=0x7f7a88134720, rs=0x45aa3ca0, which=op_search, oi=0x842da0, on=0x0) at /usr/src/openldap_2.4.15.orig/servers/slapd/backover.c:669 #7 0x0000000000496d53 in over_op_func (op=0x7f7a88134720, rs=0x7f7a88000090, which=2390608272) at /usr/src/openldap_2.4.15.orig/servers/slapd/backover.c:721 #8 0x0000000000434811 in fe_op_search (op=0x7f7a88134720, rs=0x45aa3ca0) at /usr/src/openldap_2.4.15.orig/servers/slapd/search.c:366 #9 0x000000000043500c in do_search (op=0x7f7a88134720, rs=0x45aa3ca0) at /usr/src/openldap_2.4.15.orig/servers/slapd/search.c:217 #10 0x0000000000432666 in connection_operation (ctx=0x45aa3e00, arg_v=<value optimized out>) at /usr/src/openldap_2.4.15.orig/servers/slapd/connection.c:1097 #11 0x000000000043315d in connection_read_thread (ctx=0x45aa3e00, argv=<value optimized out>) at /usr/src/openldap_2.4.15.orig/servers/slapd/connection.c:1223 #12 0x00007f7a9042314a in ldap_int_thread_pool_wrapper ( xpool=<value optimized out>) at /usr/src/openldap_2.4.15.orig/libraries/libldap_r/tpool.c:663 #13 0x00007f7a8e7d2fc7 in start_thread () from /lib/libpthread.so.0 #14 0x00007f7a8e5485ad in clone () from /lib/libc.so.6 #15 0x0000000000000000 in ?? () Thread 11 (Thread 0x452a3950 (LWP 3516)): #0 0x00007f7a8e7d6d29 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 #1 0x00007f7a9042319d in ldap_int_thread_pool_wrapper ( xpool=<value optimized out>) at /usr/src/openldap_2.4.15.orig/libraries/libldap_r/tpool.c:654 ---Type <return> to continue, or q <return> to quit--- #2 0x00007f7a8e7d2fc7 in start_thread () from /lib/libpthread.so.0 #3 0x00007f7a8e5485ad in clone () from /lib/libc.so.6 #4 0x0000000000000000 in ?? () Thread 10 (Thread 0x44aa2950 (LWP 3515)): #0 0x00007f7a8e7d6d29 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 #1 0x00007f7a9042319d in ldap_int_thread_pool_wrapper ( xpool=<value optimized out>) at /usr/src/openldap_2.4.15.orig/libraries/libldap_r/tpool.c:654 #2 0x00007f7a8e7d2fc7 in start_thread () from /lib/libpthread.so.0 #3 0x00007f7a8e5485ad in clone () from /lib/libc.so.6 #4 0x0000000000000000 in ?? () Thread 9 (Thread 0x442a1950 (LWP 3514)): #0 0x00007f7a8e7d6d29 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 #1 0x00007f7a9042319d in ldap_int_thread_pool_wrapper ( xpool=<value optimized out>) at /usr/src/openldap_2.4.15.orig/libraries/libldap_r/tpool.c:654 #2 0x00007f7a8e7d2fc7 in start_thread () from /lib/libpthread.so.0 #3 0x00007f7a8e5485ad in clone () from /lib/libc.so.6 #4 0x0000000000000000 in ?? () Thread 8 (Thread 0x43aa0950 (LWP 3513)): #0 0x00007f7a8e7d6d29 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 #1 0x00007f7a9042319d in ldap_int_thread_pool_wrapper ( xpool=<value optimized out>) at /usr/src/openldap_2.4.15.orig/libraries/libldap_r/tpool.c:654 #2 0x00007f7a8e7d2fc7 in start_thread () from /lib/libpthread.so.0 #3 0x00007f7a8e5485ad in clone () from /lib/libc.so.6 #4 0x0000000000000000 in ?? () Thread 7 (Thread 0x40b02950 (LWP 3512)): #0 0x00007f7a8e7d6d29 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 #1 0x00007f7a9042319d in ldap_int_thread_pool_wrapper ( xpool=<value optimized out>) at /usr/src/openldap_2.4.15.orig/libraries/libldap_r/tpool.c:654 #2 0x00007f7a8e7d2fc7 in start_thread () from /lib/libpthread.so.0 #3 0x00007f7a8e5485ad in clone () from /lib/libc.so.6 #4 0x0000000000000000 in ?? () Thread 6 (Thread 0x4329f950 (LWP 3042)): #0 0x00007f7a8e7d6d29 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 ---Type <return> to continue, or q <return> to quit--- #1 0x00007f7a9042319d in ldap_int_thread_pool_wrapper ( xpool=<value optimized out>) at /usr/src/openldap_2.4.15.orig/libraries/libldap_r/tpool.c:654 #2 0x00007f7a8e7d2fc7 in start_thread () from /lib/libpthread.so.0 #3 0x00007f7a8e5485ad in clone () from /lib/libc.so.6 #4 0x0000000000000000 in ?? () Thread 5 (Thread 0x42a9e950 (LWP 2274)): #0 0x00007f7a8e7d6d29 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 #1 0x00007f7a9042319d in ldap_int_thread_pool_wrapper ( xpool=<value optimized out>) at /usr/src/openldap_2.4.15.orig/libraries/libldap_r/tpool.c:654 #2 0x00007f7a8e7d2fc7 in start_thread () from /lib/libpthread.so.0 #3 0x00007f7a8e5485ad in clone () from /lib/libc.so.6 #4 0x0000000000000000 in ?? () Thread 4 (Thread 0x4229d950 (LWP 2273)): #0 0x00007f7a8e7d6d29 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 #1 0x00007f7a9042319d in ldap_int_thread_pool_wrapper ( xpool=<value optimized out>) at /usr/src/openldap_2.4.15.orig/libraries/libldap_r/tpool.c:654 #2 0x00007f7a8e7d2fc7 in start_thread () from /lib/libpthread.so.0 #3 0x00007f7a8e5485ad in clone () from /lib/libc.so.6 #4 0x0000000000000000 in ?? () Thread 3 (Thread 0x41a9c950 (LWP 2272)): #0 0x00007f7a8e548b78 in epoll_wait () from /lib/libc.so.6 #1 0x000000000042f820 in slapd_daemon_task (ptr=<value optimized out>) at /usr/src/openldap_2.4.15.orig/servers/slapd/daemon.c:2291 #2 0x00007f7a8e7d2fc7 in start_thread () from /lib/libpthread.so.0 #3 0x00007f7a8e5485ad in clone () from /lib/libc.so.6 #4 0x0000000000000000 in ?? () Thread 1 (Thread 0x7f7a908686e0 (LWP 2267)): #0 0x00007f7a8e7d3715 in pthread_join () from /lib/libpthread.so.0 #1 0x000000000042ca1c in slapd_daemon () at /usr/src/openldap_2.4.15.orig/servers/slapd/daemon.c:2665 #2 0x000000000041a9f7 in main (argc=11, argv=0x7fff988784a8) at /usr/src/openldap_2.4.15.orig/servers/slapd/main.c:948 #0 0x00007f7a8e7d44aa in pthread_mutex_lock () from /lib/libpthread.so.0 (gdb)

1 0

Re: (ITS#6182) Is openldap2.2.26 compile/make supported on AIX5.3?
by hyc＠symas.com 21 Jun '09

21 Jun '09

gopinath.in.svu(a)gmail.com wrote: > Full_Name: Gopi nath > Version: 2.2.26 > OS: AIX 5.3 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (210.210.79.19) > Software usage questions belong on the openldap-software mailing list. OpenLDAP 2.2 was obsoleted several years ago, and questions about it will not be answered. The current version is 2.4. This ITS will be closed. > I am trying to compile openldap 2.2.26 on AIX 5.3 OS. It is giving problems > saying: > > [exec] checking for db.h... no > [exec] configure: error: BDB/HDB: BerkeleyDB not available > [exec] make: 1254-002 Cannot find a rule to create target clean from > dependencies. > [exec] Stop. > [exec] make: 1254-002 Cannot find a rule to create target depend from > dependencies. > [exec] Stop. > [exec] make: make 1254-025 There must be an existing description file or > specify a target. > [exec] make: 1254-002 Cannot find a rule to create target test from > dependencies. > [exec] Stop. > [exec] make: 1254-002 Cannot find a rule to create target install from > dependencies. > [exec] Stop. > -- -- 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#6170) test039 seg faults
by michael＠stroeder.com 21 Jun '09

21 Jun '09

Seg faulted again. Take two of tests/testrun/ available under: http://www.stroeder.com/temp/openldap/its6170_test039-testrun2.tar.gz I really wonder why I have such subtle issues which are not deterministic. Maybe it's because I'm running make test on an old laptop with Pentium Mobile 1,8 GHz which is rather slow? I tested with default values SLEEP1=7 and SLEEP2=15. Even if these values are too low for this particular system slapd should never ever seg fault. ------------------------ test output ------------------------ >>>>> Starting test039-glue-ldap-concurrency ... running defines.sh Starting slapd on TCP/IP port 9011... Using ldapsearch to check that slapd is running... Using ldapadd to populate the database... Starting slapd on TCP/IP port 9012... Using ldapsearch to check that slapd is running... Using ldapadd to populate the database... Starting slapd on TCP/IP port 9013... Using ldapsearch to check that slapd is running... MONITORDB mod SRCDIR /usr/src/michael/openldap/OPENLDAP_REL_ENG_2_4/openldap/tests/testrun/./testdata DSTDIR /usr/src/michael/openldap/OPENLDAP_REL_ENG_2_4/openldap/tests/testrun pwd /usr/src/michael/openldap/OPENLDAP_REL_ENG_2_4/openldap/tests Using tester for concurrent server access... PID=15124 - Search(500): base="o=Example,c=US" scope=sub filter="(cn=Barbara Jensen)" attrs=cn (more...). PID=15126 - Read(1000): entry="cn=Barbara Jensen,ou=Information Technology Division,ou=People,o=Example,c=US". PID=15130 - Modrdn(50): entry="cn=Dorothy Stevens,ou=Alumni Association,ou=People,o=Example,c=US". PID=15137 - Modify(50): entry="cn=Barbara Jensen,ou=Information Technology Division,ou=People,o=Example,c=US". PID=15141 - Add/Delete(50): entry="cn=James A Jones 3,ou=Alumni Association,ou=People,o=Example,c=US". PID=15156 - Search(500): base="ou=people,o=Example,c=US" scope=sub filter="(cn=Bjorn Jensen)" attrs=cn (more...). PID=15149 - Bind(1000): dn="cn=Barbara Jensen,ou=Information Technology Division,ou=People,o=Example,c=US". PID=15164 - Read(1000): entry="cn=ITD Staff,ou=Groups,o=Example,c=US". slapd-bind PID=15149: ldap_sasl_bind_s: Invalid credentials (49) PID=15178 - Modrdn(50): entry="cn=John Doe,ou=Information Technology Division,ou=People,o=Example,c=US". PID=15189 - Modify(50): entry="cn=Bjorn Jensen,ou=Information Technology Division,ou=People,o=Example,c=US". PID=15203 - Add/Delete(50): entry="cn=James A Jones 5,o=Example,c=US". PID=15234 - Search(500): base="ou=people,o=Example,c=US" scope=sub filter="(cn=James A Jones 1)" attrs=cn (more...). PID=15217 - Bind(1000): dn="cn=Bjorn Jensen,ou=Information Technology Division,ou=People,o=Example,c=US". PID=15248 - Read(1000): entry="ou=Groups, o=Example,c=US". PID=15263 - Modrdn(50): entry="cn=Ursula Hampster,ou=Alumni Association,ou=People,o=Example,c=US". PID=15282 - Modify(50): entry="cn=James A Jones 1,ou=Alumni Association,ou=People,o=Example,c=US". PID=15296 - Add/Delete(50): entry="cn=James A Jones 2,ou=Alumni Association,ou=People,o=Example,c=US". PID=15308 - Bind(1000): base="ou=People,o=Example,c=US", filter="(userPassword=*)" attr="userPassword". PID=15344 - Read(1000): entry="ou=Alumni Association, ou=People, o=Example,c=US". PID=15329 - Search(500): base="o=Example,c=US" scope=sub filter="(cn=Bjorn Jensen)" attrs=cn (more...). PID=15308 - Bind base="ou=People,o=Example,c=US" filter="(userPassword=*)" got 3 values. slapd-bind PID=15308: ldap_sasl_bind_s: Invalid credentials (49) slapd-search PID=15124: ldap_search_ext_s: Can't contact LDAP server (-1) base="o=Example,c=US" filter="(cn=Barbara Jensen)" PID=15124 - Search done (-1). slapd-read PID=15126: ldap_search_ext_s(cn=Barbara Jensen,ou=Information Technology Division,ou=People,o=Example,c=US): Can't contact LDAP server (-1) PID=15126 - Read done (-1). slapd-modrdn PID=15130: ldap_rename_s: Can't contact LDAP server (-1) PID=15130 - Modrdn done (-1). slapd-modify PID=15137: ldap_modify_ext_s: Can't contact LDAP server (-1) PID=15137 - Modify done (-1). slapd-addel PID=15141: ldap_delete_ext_s: Can't contact LDAP server (-1) PID=15141 - Add/Delete done (-1). slapd-bind PID=15149: ldap_sasl_bind_s: Can't contact LDAP server (-1) PID=15149 - Bind done (-1). slapd-search PID=15156: ldap_search_ext_s: Can't contact LDAP server (-1) base="ou=people,o=Example,c=US" filter="(cn=Bjorn Jensen)" PID=15156 - Search done (-1). slapd-modrdn PID=15263: ldap_rename_s: Can't contact LDAP server (-1) PID=15263 - Modrdn done (-1). slapd-read PID=15164: ldap_search_ext_s(cn=ITD Staff,ou=Groups,o=Example,c=US): Can't contact LDAP server (-1) PID=15164 - Read done (-1). slapd-modrdn PID=15178: ldap_rename_s: Can't contact LDAP server (-1) PID=15178 - Modrdn done (-1). slapd-modify PID=15189: ldap_modify_ext_s: Can't contact LDAP server (-1) PID=15189 - Modify done (-1). slapd-addel PID=15203: ldap_add_ext_s: Can't contact LDAP server (-1) PID=15203 - Add/Delete done (-1). slapd-search PID=15234: ldap_search_ext_s: Can't contact LDAP server (-1) base="ou=people,o=Example,c=US" filter="(cn=James A Jones 1)" PID=15234 - Search done (-1). slapd-bind PID=15217: ldap_sasl_bind_s: Can't contact LDAP server (-1) PID=15217 - Bind done (-1). slapd-read PID=15248: ldap_search_ext_s(ou=Groups, o=Example,c=US): Can't contact LDAP server (-1) PID=15248 - Read done (-1). slapd-modify PID=15282: ldap_modify_ext_s: Can't contact LDAP server (-1) PID=15282 - Modify done (-1). slapd-addel PID=15296: ldap_delete_ext_s: Can't contact LDAP server (-1) PID=15296 - Add/Delete done (-1). slapd-bind PID=15308: ldap_sasl_bind_s: Can't contact LDAP server (-1) PID=15308 - Bind done 5 in 1.169805 seconds. slapd-read PID=15344: ldap_search_ext_s(ou=Alumni Association, ou=People, o=Example,c=US): Can't contact LDAP server (-1) PID=15344 - Read done (-1). slapd-search PID=15329: ldap_search_ext_s: Can't contact LDAP server (-1) base="o=Example,c=US" filter="(cn=Bjorn Jensen)" PID=15329 - Search done (-1). PID=15433 - Modrdn(50): entry="cn=James A Jones 2,ou=Information Technology Division,ou=People,o=Example,c=US". slapd-modrdn PID=15433: ldap_sasl_bind_s: Can't contact LDAP server (-1) stopping: child exited with status 1 ./scripts/test039-glue-ldap-concurrency: line 188: 15063 Aborted (core dumped) $SLAPD -f $CONF3 -h $URI3 -d $LVL $TIMING > $LOG3 2>&1 slapd-tester failed (1)! ./scripts/test039-glue-ldap-concurrency: line 193: kill: (15063) - No such process >>>>> ./scripts/test039-glue-ldap-concurrency failed (exit 1) make[2]: *** [hdb-mod] Error 1 make[2]: Leaving directory `/usr/src/michael/openldap/OPENLDAP_REL_ENG_2_4/openldap/tests' make[1]: *** [test] Error 2 make[1]: Leaving directory `/usr/src/michael/openldap/OPENLDAP_REL_ENG_2_4/openldap/tests' make: *** [test] Error 2 michael@nb2:/usr/src/michael/openldap/OPENLDAP_REL_ENG_2_4/openldap> PID=15465 - Read(1000): entry="cn=Somewhere,ou=Meta,o=Example,c=US". PID=15451 - Bind(1000): dn="". PID=15469 - Bind(1000): dn="cn=Bjorn Jensen,ou=Information Technology Division,ou=People,o=Example,c=US". PID=15459 - Bind(1000): dn="cn=Barbara Jensen,ou=Information Technology Division,ou=People,o=Example,c=US". PID=15473 - Search(500): base="cn=Monitor" scope=sub filter="(objectClass=*)" attrs=cn (more...). PID=15439 - Modify(50): entry="cn=ITD Staff,ou=Groups,o=Example,c=US". slapd-bind PID=15451: ldap_sasl_bind_s: Can't contact LDAP server (-1) PID=15451 - Bind done (-1). slapd-bind PID=15459: ldap_sasl_bind_s: Can't contact LDAP server (-1) slapd-read PID=15465: ldap_sasl_bind_s: Can't contact LDAP server (-1) slapd-bind PID=15469: ldap_sasl_bind_s: Can't contact LDAP server (-1) PID=15459 - Bind done (-1). PID=15469 - Bind done (-1). slapd-search PID=15473: ldap_sasl_bind_s: Can't contact LDAP server (-1) bindDN="cn=Manager,o=Example,c=US" PID=15453 - Search(500): base="o=Example,c=US" scope=sub filter="(cn=James*)" attrs=cn (more...). PID=15449 - Read(1000): entry="cn=James A Jones 1, ou=Alumni Association, ou=People, o=Example,c=US". slapd-modify PID=15439: ldap_sasl_bind_s: Can't contact LDAP server (-1) PID=15477 - Read(1000): entry="cn=Backend 1,cn=Backends,cn=Monitor". PID=15485 - Bind(1000): dn="cn=Foo,ou=Meta,o=Example,c=US". PID=15487 - Search(500): base="cn=Monitor" scope=sub filter="(objectClass=*)" attrs=cn (more...). PID=15481 - Search(500): base="cn=Monitor" scope=sub filter="(objectClass=*)" attrs=cn (more...). PID=15447 - Search(500): base="o=Example,c=US" scope=sub filter="(cn=Alumni Assoc Staff)" attrs=cn (more...). PID=15463 - Search(500): base="cn=Monitor" scope=sub filter="(objectClass=*)" attrs=cn (more...). PID=15445 - Bind(1000): dn="cn=Foo,ou=Meta,o=Example,c=US". PID=15483 - Read(1000): entry="cn=Entries,cn=Statistics,cn=Monitor". slapd-read PID=15449: ldap_sasl_bind_s: Can't contact LDAP server (-1) slapd-search PID=15453: ldap_sasl_bind_s: Can't contact LDAP server (-1) bindDN="cn=Manager,o=Example,c=US" PID=15443 - Add/Delete(50): entry="cn=James A Jones 4,ou=People,o=Example,c=US". slapd-search PID=15463: ldap_sasl_bind_s: Can't contact LDAP server (-1) bindDN="cn=Manager,o=Example,c=US" slapd-read PID=15477: ldap_sasl_bind_s: Can't contact LDAP server (-1) slapd-addel PID=15443: ldap_sasl_bind_s: Can't contact LDAP server (-1) slapd-bind PID=15485: ldap_sasl_bind_s: Can't contact LDAP server (-1) PID=15485 - Bind done (-1). slapd-bind PID=15479: ldap_sasl_bind_s: Can't contact LDAP server (-1) slapd-search PID=15487: ldap_sasl_bind_s: Can't contact LDAP server (-1) bindDN="cn=Manager,o=Example,c=US" slapd-search PID=15481: ldap_sasl_bind_s: Can't contact LDAP server (-1) bindDN="cn=Manager,o=Example,c=US" slapd-search PID=15447: ldap_sasl_bind_s: Can't contact LDAP server (-1) bindDN="cn=Manager,o=Example,c=US" PID=15455 - Read(1000): entry="ou=Meta,o=Example,c=US". slapd-bind PID=15445: ldap_sasl_bind_s: Can't contact LDAP server (-1) PID=15445 - Bind done (-1). slapd-read PID=15483: ldap_sasl_bind_s: Can't contact LDAP server (-1) slapd-read PID=15455: ldap_sasl_bind_s: Can't contact LDAP server (-1) michael@nb2:/usr/src/michael/openldap/OPENLDAP_REL_ENG_2_4/openldap> l tests/core.15063 -rw------- 1 michael users 91799552 2009-06-21 14:55 tests/core.15063 ------------------------------ gdb output ------------------------------ michael@nb2:/usr/src/michael/openldap/OPENLDAP_REL_ENG_2_4/openldap/tests> gdb --core=core.15063 --exec=../servers/slapd/.libs/lt-slapd GNU gdb (GDB; openSUSE 11.1) 6.8.50.20081120-cvs Copyright (C) 2008 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "i586-suse-linux". For bug reporting instructions, please see: <http://bugs.opensuse.org/>. warning: Can't read pathname for load map: Input/output error. Reading symbols from /usr/src/michael/openldap/OPENLDAP_REL_ENG_2_4/openldap/libraries/libldap_r/.libs/libldap_r-2.4-releng.so.2...done. Loaded symbols for /usr/src/michael/openldap/OPENLDAP_REL_ENG_2_4/openldap/libraries/libldap_r/.libs/libldap_r-2.4-releng.so.2 Reading symbols from /usr/src/michael/openldap/OPENLDAP_REL_ENG_2_4/openldap/libraries/liblber/.libs/liblber-2.4-releng.so.2...done. Loaded symbols for /usr/src/michael/openldap/OPENLDAP_REL_ENG_2_4/openldap/libraries/liblber/.libs/liblber-2.4-releng.so.2 Reading symbols from /lib/libuuid.so.1...done. Loaded symbols for /lib/libuuid.so.1 Reading symbols from /usr/lib/libdb-4.5.so...done. Loaded symbols for /usr/lib/libdb-4.5.so Reading symbols from /usr/lib/libodbc.so.1...done. Loaded symbols for /usr/lib/libodbc.so.1 Reading symbols from /lib/libpthread.so.0...done. Loaded symbols for /lib/libpthread.so.0 Reading symbols from /usr/lib/libsasl2.so.2...done. Loaded symbols for /usr/lib/libsasl2.so.2 Reading symbols from /usr/lib/libgssapi_krb5.so.2...done. Loaded symbols for /usr/lib/libgssapi_krb5.so.2 Reading symbols from /usr/lib/libssl.so.0.9.8...done. Loaded symbols for /usr/lib/libssl.so.0.9.8 Reading symbols from /usr/lib/libcrypto.so.0.9.8...done. Loaded symbols for /usr/lib/libcrypto.so.0.9.8 Reading symbols from /lib/libcrypt.so.1...done. Loaded symbols for /lib/libcrypt.so.1 Reading symbols from /lib/libresolv.so.2...done. Loaded symbols for /lib/libresolv.so.2 Reading symbols from /usr/lib/libltdl.so.7...done. Loaded symbols for /usr/lib/libltdl.so.7 Reading symbols from /lib/libdl.so.2...done. Loaded symbols for /lib/libdl.so.2 Reading symbols from /lib/libc.so.6...done. Loaded symbols for /lib/libc.so.6 Reading symbols from /lib/ld-linux.so.2...done. Loaded symbols for /lib/ld-linux.so.2 Reading symbols from /usr/lib/libkrb5.so.3...done. Loaded symbols for /usr/lib/libkrb5.so.3 Reading symbols from /usr/lib/libk5crypto.so.3...done. Loaded symbols for /usr/lib/libk5crypto.so.3 Reading symbols from /lib/libcom_err.so.2...done. Loaded symbols for /lib/libcom_err.so.2 Reading symbols from /usr/lib/libkrb5support.so.0...done. Loaded symbols for /usr/lib/libkrb5support.so.0 Reading symbols from /lib/libkeyutils.so.1...done. Loaded symbols for /lib/libkeyutils.so.1 Reading symbols from /lib/libz.so.1...done. Loaded symbols for /lib/libz.so.1 Reading symbols from /lib/libnss_files.so.2...done. Loaded symbols for /lib/libnss_files.so.2 Reading symbols from /usr/lib/sasl2/libcrammd5.so...done. Loaded symbols for /usr/lib/sasl2/libcrammd5.so Reading symbols from /usr/lib/sasl2/liblogin.so...done. Loaded symbols for /usr/lib/sasl2/liblogin.so Reading symbols from /usr/lib/sasl2/libsasldb.so...done. Loaded symbols for /usr/lib/sasl2/libsasldb.so Reading symbols from /usr/lib/sasl2/libotp.so...done. Loaded symbols for /usr/lib/sasl2/libotp.so Reading symbols from /usr/lib/sasl2/libplain.so...done. Loaded symbols for /usr/lib/sasl2/libplain.so Reading symbols from /usr/lib/sasl2/libgssapiv2.so...done. Loaded symbols for /usr/lib/sasl2/libgssapiv2.so Reading symbols from /usr/lib/sasl2/libdigestmd5.so...done. Loaded symbols for /usr/lib/sasl2/libdigestmd5.so Reading symbols from /usr/lib/sasl2/libanonymous.so...done. Loaded symbols for /usr/lib/sasl2/libanonymous.so Reading symbols from /usr/lib/sasl2/libntlm.so...done. Loaded symbols for /usr/lib/sasl2/libntlm.so Reading symbols from /usr/src/michael/openldap/OPENLDAP_REL_ENG_2_4/openldap/servers/slapd/back-hdb/.libs/back_hdb-2.4-releng.so.2...done. Loaded symbols for ../servers/slapd/back-hdb/.libs/back_hdb-2.4-releng.so.2 Reading symbols from /usr/src/michael/openldap/OPENLDAP_REL_ENG_2_4/openldap/servers/slapd/back-relay/.libs/back_relay-2.4-releng.so.2...done. Loaded symbols for ../servers/slapd/back-relay/.libs/back_relay-2.4-releng.so.2 Reading symbols from /usr/src/michael/openldap/OPENLDAP_REL_ENG_2_4/openldap/servers/slapd/back-ldap/.libs/back_ldap-2.4-releng.so.2...done. Loaded symbols for ../servers/slapd/back-ldap/.libs/back_ldap-2.4-releng.so.2 Reading symbols from /usr/src/michael/openldap/OPENLDAP_REL_ENG_2_4/openldap/servers/slapd/back-meta/.libs/back_meta-2.4-releng.so.2...done. Loaded symbols for ../servers/slapd/back-meta/.libs/back_meta-2.4-releng.so.2 Reading symbols from /usr/src/michael/openldap/OPENLDAP_REL_ENG_2_4/openldap/servers/slapd/back-monitor/.libs/back_monitor-2.4-releng.so.2...done. Loaded symbols for ../servers/slapd/back-monitor/.libs/back_monitor-2.4-releng.so.2 Reading symbols from /usr/src/michael/openldap/OPENLDAP_REL_ENG_2_4/openldap/servers/slapd/overlays/.libs/rwm-2.4-releng.so.2...done. Loaded symbols for ../servers/slapd/overlays/.libs/rwm-2.4-releng.so.2 [New Thread 15341] [New Thread 15063] [New Thread 15340] [New Thread 15254] [New Thread 15312] [New Thread 15410] [New Thread 15384] [New Thread 15209] [New Thread 15283] [New Thread 15366] [New Thread 15093] [New Thread 15313] [New Thread 15298] [New Thread 15417] [New Thread 15078] [New Thread 15232] [New Thread 15396] Core was generated by `/usr/src/michael/openldap/OPENLDAP_REL_ENG_2_4/openldap/servers/slapd/.libs/lt-'. Program terminated with signal 6, Aborted. #0 0xffffe430 in __kernel_vsyscall () (gdb) info threads 18 Thread 15396 0xffffe430 in __kernel_vsyscall () 17 Thread 15232 0x08077b90 in ?? () 16 Thread 15078 0xffffe430 in __kernel_vsyscall () 15 Thread 15417 0xffffe430 in __kernel_vsyscall () 14 Thread 15298 0xffffe430 in __kernel_vsyscall () 13 Thread 15313 0xffffe430 in __kernel_vsyscall () 12 Thread 15093 0xffffe430 in __kernel_vsyscall () 11 Thread 15366 0xffffe430 in __kernel_vsyscall () 10 Thread 15283 0xffffe430 in __kernel_vsyscall () 9 Thread 15209 0xffffe430 in __kernel_vsyscall () 8 Thread 15384 0xffffe430 in __kernel_vsyscall () 7 Thread 15410 0xffffe430 in __kernel_vsyscall () 6 Thread 15312 0xffffe430 in __kernel_vsyscall () 5 Thread 15254 0xffffe430 in __kernel_vsyscall () 4 Thread 15340 0xffffe430 in __kernel_vsyscall () 3 Thread 15063 0xffffe430 in __kernel_vsyscall () 2 Thread 15341 0xffffe430 in __kernel_vsyscall () * 1 Thread 15348 0xffffe430 in __kernel_vsyscall () (gdb) thread apply all bt Thread 18 (Thread 15396): #0 0xffffe430 in __kernel_vsyscall () #1 0x40250b3b in write () from /lib/libpthread.so.0 #2 0x400744eb in sb_stream_write (sbiod=0x82b6ab8, buf=0x4517356c, len=15) at sockbuf.c:535 #3 0x4007362a in sb_debug_write (sbiod=0x82b6860, buf=0x4517356c, len=15) at sockbuf.c:852 #4 0x40073a32 in ber_int_sb_write (sb=0x82b6ae0, buf=0x4517356c, len=15) at sockbuf.c:445 #5 0x40071284 in ber_flush2 (sb=0x82b6ae0, ber=0x4516fa9c, freeit=0) at io.c:256 #6 0x08087cb7 in ?? () #7 0x0808a575 in ?? () #8 0x0808b23f in ?? () #9 0x40789624 in ldap_back_search (op=0x82efbc8, rs=0x451710c8) at search.c:575 #10 0x080e05fc in ?? () #11 0x080e10f4 in ?? () #12 0x08079703 in ?? () #13 0x080e05fc in ?? () #14 0x080e10f4 in ?? () #15 0x08079f78 in ?? () #16 0x080772ff in ?? () #17 0x08077c87 in ?? () #18 0x4002f430 in ldap_int_thread_pool_wrapper (xpool=0x8) at tpool.c:698 #19 0x4024a1b5 in start_thread () from /lib/libpthread.so.0 #20 0x405863be in clone () from /lib/libc.so.6 Thread 17 (Thread 15232): #0 0x08077b90 in ?? () #1 0x4002f430 in ldap_int_thread_pool_wrapper (xpool=0x407ea218) at tpool.c:698 #2 0x4024a1b5 in start_thread () from /lib/libpthread.so.0 #3 0x405863be in clone () from /lib/libc.so.6 Thread 16 (Thread 15078): #0 0xffffe430 in __kernel_vsyscall () #1 0x40586c56 in epoll_wait () from /lib/libc.so.6 #2 0x08073cf7 in ?? () #3 0x4024a1b5 in start_thread () from /lib/libpthread.so.0 #4 0x405863be in clone () from /lib/libc.so.6 Thread 15 (Thread 15417): #0 0xffffe430 in __kernel_vsyscall () #1 0x4057c6a7 in poll () from /lib/libc.so.6 #2 0x40049f65 in ldap_int_select (ld=0x82afde8, timeout=0x45b73af0) at os-ip.c:1056 #3 0x40031d1f in ldap_result (ld=0x82afde8, msgid=8, all=0, timeout=0x45b73c1c, result=0x45b73c34) at result.c:335 #4 0x40789923 in ldap_back_search (op=0x82ae2d8, rs=0x45b750c8) at search.c:276 #5 0x080de220 in ?? () #6 0x080def93 in ?? () #7 0x080e0586 in ?? () #8 0x080e10f4 in ?? () #9 0x08079703 in ?? () #10 0x080e05fc in ?? () #11 0x080e10f4 in ?? () #12 0x08079f78 in ?? () #13 0x080772ff in ?? () #14 0x08077c87 in ?? () #15 0x4002f430 in ldap_int_thread_pool_wrapper (xpool=0x45b750c8) at tpool.c:698 #16 0x4024a1b5 in start_thread () from /lib/libpthread.so.0 #17 0x405863be in clone () from /lib/libc.so.6 Thread 14 (Thread 15298): #0 0xffffe430 in __kernel_vsyscall () #1 0x4057c6a7 in poll () from /lib/libc.so.6 #2 0x40049f65 in ldap_int_select (ld=0x82b6078, timeout=0x4295faf0) at os-ip.c:1056 #3 0x40031d1f in ldap_result (ld=0x82b6078, msgid=4, all=0, timeout=0x4295fc1c, result=0x4295fc34) at result.c:335 #4 0x40789923 in ldap_back_search (op=0x82b64e8, rs=0x429610c8) at search.c:276 #5 0x080de220 in ?? () #6 0x080defd8 in ?? () #7 0x080e0586 in ?? () #8 0x080e10f4 in ?? () #9 0x08079703 in ?? () #10 0x080e05fc in ?? () #11 0x080e10f4 in ?? () #12 0x08079f78 in ?? () #13 0x080772ff in ?? () #14 0x08077c87 in ?? () #15 0x4002f430 in ldap_int_thread_pool_wrapper (xpool=0x429610c8) at tpool.c:698 #16 0x4024a1b5 in start_thread () from /lib/libpthread.so.0 #17 0x405863be in clone () from /lib/libc.so.6 Thread 13 (Thread 15313): #0 0xffffe430 in __kernel_vsyscall () #1 0x4057c6a7 in poll () from /lib/libc.so.6 #2 0x40049f65 in ldap_int_select (ld=0x826a570, timeout=0x43161a00) at os-ip.c:1056 #3 0x40031d1f in ldap_result (ld=0x826a570, msgid=668, all=1, timeout=0x43161a80, result=0x43161a88) at result.c:335 #4 0x4078d371 in ldap_back_op_result (lc=0x826a530, op=0x829e9d8, rs=0x431630c8, msgid=668, timeout=0, sendok=LDAP_BACK_RETRY_SRES) at bind.c:1704 #5 0x4078fadb in ldap_back_modify (op=0x829e9d8, rs=0x431630c8) at modify.c:111 #6 0x080e05fc in ?? () #7 0x080e10f4 in ?? () #8 0x0809082d in ?? () #9 0x080e05fc in ?? () #10 0x080e10f4 in ?? () #11 0x0809136f in ?? () #12 0x080772ff in ?? () #13 0x08077c87 in ?? () #14 0x4002f430 in ldap_int_thread_pool_wrapper (xpool=0x10) at tpool.c:698 #15 0x4024a1b5 in start_thread () from /lib/libpthread.so.0 #16 0x405863be in clone () from /lib/libc.so.6 Thread 12 (Thread 15093): #0 0xffffe430 in __kernel_vsyscall () #1 0x4057c6a7 in poll () from /lib/libc.so.6 #2 0x40049f65 in ldap_int_select (ld=0x82e4d88, timeout=0x41055bc0) at os-ip.c:1056 #3 0x40031d1f in ldap_result (ld=0x82e4d88, msgid=4, all=0, timeout=0x41055cec, result=0x41055d04) at result.c:335 #4 0x40789923 in ldap_back_search (op=0x825ea80, rs=0x410570c8) at search.c:276 #5 0x080e05fc in ?? () #6 0x080e10f4 in ?? () #7 0x08079703 in ?? () #8 0x080e05fc in ?? () #9 0x080e10f4 in ?? () #10 0x08079f78 in ?? () #11 0x080772ff in ?? () #12 0x08077c87 in ?? () #13 0x4002f430 in ldap_int_thread_pool_wrapper (xpool=0x8) at tpool.c:698 #14 0x4024a1b5 in start_thread () from /lib/libpthread.so.0 #15 0x405863be in clone () from /lib/libc.so.6 Thread 11 (Thread 15366): #0 0xffffe430 in __kernel_vsyscall () #1 0x4057c6a7 in poll () from /lib/libc.so.6 #2 0x40049f65 in ldap_int_select (ld=0x82b9b60, timeout=0x4476baf0) at os-ip.c:1056 #3 0x40031d1f in ldap_result (ld=0x82b9b60, msgid=10, all=0, timeout=0x4476bc1c, result=0x4476bc34) at result.c:335 #4 0x40789923 in ldap_back_search (op=0x82e1828, rs=0x4476d0c8) at search.c:276 #5 0x080de220 in ?? () #6 0x080defd8 in ?? () #7 0x080e0586 in ?? () #8 0x080e10f4 in ?? () #9 0x08079703 in ?? () #10 0x080e05fc in ?? () #11 0x080e10f4 in ?? () #12 0x08079f78 in ?? () #13 0x080772ff in ?? () #14 0x08077c87 in ?? () #15 0x4002f430 in ldap_int_thread_pool_wrapper (xpool=0x4476d0c8) at tpool.c:698 #16 0x4024a1b5 in start_thread () from /lib/libpthread.so.0 #17 0x405863be in clone () from /lib/libc.so.6 Thread 10 (Thread 15283): #0 0xffffe430 in __kernel_vsyscall () #1 0x4057c6a7 in poll () from /lib/libc.so.6 #2 0x40049f65 in ldap_int_select (ld=0x830dbb0, timeout=0x4245dbc0) at os-ip.c:1056 #3 0x40031d1f in ldap_result (ld=0x830dbb0, msgid=504, all=0, timeout=0x4245dcec, result=0x4245dd04) at result.c:335 #4 0x40789923 in ldap_back_search (op=0x8293608, rs=0x4245f0c8) at search.c:276 #5 0x080e05fc in ?? () #6 0x080e10f4 in ?? () #7 0x08079703 in ?? () #8 0x080e05fc in ?? () #9 0x080e10f4 in ?? () #10 0x08079f78 in ?? () #11 0x080772ff in ?? () #12 0x08077c87 in ?? () #13 0x4002f430 in ldap_int_thread_pool_wrapper (xpool=0x8) at tpool.c:698 #14 0x4024a1b5 in start_thread () from /lib/libpthread.so.0 #15 0x405863be in clone () from /lib/libc.so.6 Thread 9 (Thread 15209): #0 0xffffe430 in __kernel_vsyscall () #1 0x4057c6a7 in poll () from /lib/libc.so.6 #2 0x40049f65 in ldap_int_select (ld=0x830e2f8, timeout=0x41558bc0) at os-ip.c:1056 #3 0x40031d1f in ldap_result (ld=0x830e2f8, msgid=1120, all=1, timeout=0x41558c40, result=0x41558c48) at result.c:335 #4 0x4078d371 in ldap_back_op_result (lc=0x82a11b8, op=0x8272c88, rs=0x415590c8, msgid=1120, timeout=0, sendok=LDAP_BACK_RETRY_SRES) at bind.c:1704 #5 0x4078f75a in ldap_back_delete (op=0x8272c88, rs=0x415590c8) at delete.c:62 #6 0x080e05fc in ?? () #7 0x080e10f4 in ?? () #8 0x080917cb in ?? () #9 0x080e05fc in ?? () #10 0x080e10f4 in ?? () #11 0x08091d86 in ?? () #12 0x080772ff in ?? () #13 0x08077c87 in ?? () #14 0x4002f430 in ldap_int_thread_pool_wrapper (xpool=0x1c) at tpool.c:698 #15 0x4024a1b5 in start_thread () from /lib/libpthread.so.0 #16 0x405863be in clone () from /lib/libc.so.6 Thread 8 (Thread 15384): #0 0xffffe430 in __kernel_vsyscall () #1 0x4057c6a7 in poll () from /lib/libc.so.6 #2 0x40049f65 in ldap_int_select (ld=0x8288200, timeout=0x44c6daf0) at os-ip.c:1056 #3 0x40031d1f in ldap_result (ld=0x8288200, msgid=28, all=0, timeout=0x44c6dc1c, result=0x44c6dc34) at result.c:335 #4 0x40789923 in ldap_back_search (op=0x82ef198, rs=0x44c6f0c8) at search.c:276 #5 0x080de220 in ?? () #6 0x080def93 in ?? () #7 0x080e0586 in ?? () #8 0x080e10f4 in ?? () #9 0x08079703 in ?? () #10 0x080e05fc in ?? () #11 0x080e10f4 in ?? () #12 0x08079f78 in ?? () #13 0x080772ff in ?? () #14 0x08077c87 in ?? () #15 0x4002f430 in ldap_int_thread_pool_wrapper (xpool=0x44c6f0c8) at tpool.c:698 #16 0x4024a1b5 in start_thread () from /lib/libpthread.so.0 #17 0x405863be in clone () from /lib/libc.so.6 Thread 7 (Thread 15410): #0 0xffffe430 in __kernel_vsyscall () #1 0x4057c6a7 in poll () from /lib/libc.so.6 #2 0x40049f65 in ldap_int_select (ld=0x82cb590, timeout=0x45672bc0) at os-ip.c:1056 #3 0x40031d1f in ldap_result (ld=0x82cb590, msgid=19, all=1, timeout=0x45672c40, result=0x45672c48) at result.c:335 #4 0x4078d371 in ldap_back_op_result (lc=0x82cb550, op=0x830e008, rs=0x456730c8, msgid=19, timeout=0, sendok=LDAP_BACK_RETRY_SRES) at bind.c:1704 #5 0x4078f75a in ldap_back_delete (op=0x830e008, rs=0x456730c8) at delete.c:62 #6 0x080e05fc in ?? () #7 0x080e10f4 in ?? () #8 0x080917cb in ?? () #9 0x080e05fc in ?? () #10 0x080e10f4 in ?? () #11 0x08091d86 in ?? () #12 0x080772ff in ?? () #13 0x08077c87 in ?? () #14 0x4002f430 in ldap_int_thread_pool_wrapper (xpool=0x1c) at tpool.c:698 #15 0x4024a1b5 in start_thread () from /lib/libpthread.so.0 #16 0x405863be in clone () from /lib/libc.so.6 Thread 6 (Thread 15312): #0 0xffffe430 in __kernel_vsyscall () #1 0x4057c6a7 in poll () from /lib/libc.so.6 #2 0x40049f65 in ldap_int_select (ld=0x828aae8, timeout=0x42d61b50) at os-ip.c:1056 #3 0x40031d1f in ldap_result (ld=0x828aae8, msgid=2, all=1, timeout=0x42d61bd0, result=0x42d61bd8) at result.c:335 #4 0x4078d371 in ldap_back_op_result (lc=0x828a948, op=0x82b93f0, rs=0x42d620c8, msgid=2, timeout=0, sendok=LDAP_BACK_RETRY_SRES) at bind.c:1704 #5 0x4078fd4f in ldap_back_modrdn (op=0x82b93f0, rs=0x42d620c8) at modrdn.c:95 #6 0x080e05fc in ?? () #7 0x080e10f4 in ?? () #8 0x08092b4f in ?? () #9 0x080e05fc in ?? () #10 0x080e10f4 in ?? () #11 0x080936b7 in ?? () #12 0x080772ff in ?? () #13 0x08077c87 in ?? () #14 0x4002f430 in ldap_int_thread_pool_wrapper (xpool=0x14) at tpool.c:698 #15 0x4024a1b5 in start_thread () from /lib/libpthread.so.0 #16 0x405863be in clone () from /lib/libc.so.6 Thread 5 (Thread 15254): #0 0xffffe430 in __kernel_vsyscall () #1 0x4057c6a7 in poll () from /lib/libc.so.6 #2 0x40049f65 in ldap_int_select (ld=0x82cde70, timeout=0x41f5cb50) at os-ip.c:1056 #3 0x40031d1f in ldap_result (ld=0x82cde70, msgid=2, all=1, timeout=0x41f5cbd0, result=0x41f5cbd8) at result.c:335 #4 0x4078d371 in ldap_back_op_result (lc=0x82cda80, op=0x8287e00, rs=0x41f5d0c8, msgid=2, timeout=0, sendok=LDAP_BACK_RETRY_SRES) at bind.c:1704 #5 0x4078fd4f in ldap_back_modrdn (op=0x8287e00, rs=0x41f5d0c8) at modrdn.c:95 #6 0x080e05fc in ?? () #7 0x080e10f4 in ?? () #8 0x08092b4f in ?? () #9 0x080e05fc in ?? () #10 0x080e10f4 in ?? () #11 0x080936b7 in ?? () #12 0x080772ff in ?? () #13 0x08077c87 in ?? () #14 0x4002f430 in ldap_int_thread_pool_wrapper (xpool=0x14) at tpool.c:698 #15 0x4024a1b5 in start_thread () from /lib/libpthread.so.0 #16 0x405863be in clone () from /lib/libc.so.6 Thread 4 (Thread 15340): #0 0xffffe430 in __kernel_vsyscall () #1 0x4057c6a7 in poll () from /lib/libc.so.6 #2 0x40049f65 in ldap_int_select (ld=0x82c3248, timeout=0x43865a00) at os-ip.c:1056 #3 0x40031d1f in ldap_result (ld=0x82c3248, msgid=31, all=1, timeout=0x43865a80, result=0x43865a88) at result.c:335 #4 0x4078d371 in ldap_back_op_result (lc=0x82c3190, op=0x82b6208, rs=0x438670c8, msgid=31, timeout=0, sendok=LDAP_BACK_RETRY_SRES) at bind.c:1704 #5 0x4078fadb in ldap_back_modify (op=0x82b6208, rs=0x438670c8) at modify.c:111 #6 0x080e05fc in ?? () #7 0x080e10f4 in ?? () #8 0x0809082d in ?? () #9 0x080e05fc in ?? () #10 0x080e10f4 in ?? () #11 0x0809136f in ?? () #12 0x080772ff in ?? () #13 0x08077c87 in ?? () #14 0x4002f430 in ldap_int_thread_pool_wrapper (xpool=0x10) at tpool.c:698 #15 0x4024a1b5 in start_thread () from /lib/libpthread.so.0 #16 0x405863be in clone () from /lib/libc.so.6 Thread 3 (Thread 15063): #0 0xffffe430 in __kernel_vsyscall () #1 0x4024a747 in pthread_join () from /lib/libpthread.so.0 #2 0x40030204 in ldap_pvt_thread_join (thread=1086679952, thread_return=0x0) at thr_posix.c:197 #3 0x080710f3 in ?? () #4 0x0805e205 in ?? () #5 0x404cb705 in __libc_start_main () from /lib/libc.so.6 #6 0x0805c921 in ?? () Thread 2 (Thread 15341): #0 0xffffe430 in __kernel_vsyscall () #1 0x4057c6a7 in poll () from /lib/libc.so.6 #2 0x40049f65 in ldap_int_select (ld=0x8293408, timeout=0x43c67b50) at os-ip.c:1056 #3 0x40031d1f in ldap_result (ld=0x8293408, msgid=5, all=1, timeout=0x43c67bd0, result=0x43c67bd8) at result.c:335 #4 0x4078d371 in ldap_back_op_result (lc=0x8288da0, op=0x82a0838, rs=0x43c680c8, msgid=5, timeout=0, sendok=LDAP_BACK_RETRY_SRES) at bind.c:1704 #5 0x4078fd4f in ldap_back_modrdn (op=0x82a0838, rs=0x43c680c8) at modrdn.c:95 #6 0x080e05fc in ?? () #7 0x080e10f4 in ?? () #8 0x08092b4f in ?? () #9 0x080e05fc in ?? () #10 0x080e10f4 in ?? () #11 0x080936b7 in ?? () #12 0x080772ff in ?? () #13 0x08077c87 in ?? () #14 0x4002f430 in ldap_int_thread_pool_wrapper (xpool=0x14) at tpool.c:698 #15 0x4024a1b5 in start_thread () from /lib/libpthread.so.0 #16 0x405863be in clone () from /lib/libc.so.6 Thread 1 (Thread 15348): #0 0xffffe430 in __kernel_vsyscall () #1 0x404df990 in raise () from /lib/libc.so.6 #2 0x404e12c8 in abort () from /lib/libc.so.6 #3 0x404d878e in __assert_fail () from /lib/libc.so.6 #4 0x4078c0eb in ldap_back_conn_delete (li=0x8202d90, lc=0x82b9ae0) at bind.c:157 #5 0x4078cf81 in ldap_back_freeconn (li=0x8202d90, lc=0x82b9ae0, dolock=0) at bind.c:467 #6 0x4078d059 in ldap_back_release_conn_lock (li=0x8202d90, lcp=0x4426ace8, dolock=1) at bind.c:1147 #7 0x4078ec2d in ldap_back_bind (op=0x82cbd78, rs=0x4426b0c8) at bind.c:355 #8 0x080e05fc in ?? () #9 0x080e10f4 in ?? () #10 0x08095b5c in ?? () #11 0x080e05fc in ?? () #12 0x080e10f4 in ?? () #13 0x08096692 in ?? () #14 0x080772ff in ?? () #15 0x08077c87 in ?? () #16 0x4002f430 in ldap_int_thread_pool_wrapper (xpool=0x0) at tpool.c:698 #17 0x4024a1b5 in start_thread () from /lib/libpthread.so.0 #18 0x405863be in clone () from /lib/libc.so.6

1 0

Re: (ITS#6178) test048-syncrepl-multiproxy failed (exit 1)
by michael＠stroeder.com 21 Jun '09

21 Jun '09

hyc(a)symas.com wrote: > I think your SLEEP1 is too low, the default is 7 seconds, why are you using 3 > seconds? Uuh, forgot to revert that. Normally I'm not using special values for SLEEP1 and SLEEP2 when running make test. I was trying to provoke some failures which I can't reproduce all the time. E.g. ITS#6126 but also others. I don't know how to track down these. I suspect some timing issues because the failures seems not deterministic. Ciao, Michael.

1 0

(ITS#5733) tainted connection
by richton＠nbcs.rutgers.edu 21 Jun '09

21 Jun '09

I saw this three times in testing of HEAD. One backtrace and -d -1: https://www.nbcs.rutgers.edu/~richton/test039-bt-200906200640.txt https://www.nbcs.rutgers.edu/~richton/test039-slapdlog-200906200640.txt These are under libumem with transaction logging enabled. All malloc/free for a given block can be retrieved, in theory...

1 0

(ITS#6183) Configuration examples should not be in ACL section
by ghenry＠OpenLDAP.org 19 Jun '09

19 Jun '09

Full_Name: Gavin Henry Version: HEAD OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (212.159.59.85) Submitted by: ghenry Config examples have found themselves in the ACL section.

1 0

(ITS#6182) Is openldap2.2.26 compile/make supported on AIX5.3?
by gopinath.in.svu＠gmail.com 19 Jun '09

19 Jun '09

Full_Name: Gopi nath Version: 2.2.26 OS: AIX 5.3 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (210.210.79.19) I am trying to compile openldap 2.2.26 on AIX 5.3 OS. It is giving problems saying: [exec] checking for db.h... no [exec] configure: error: BDB/HDB: BerkeleyDB not available [exec] make: 1254-002 Cannot find a rule to create target clean from dependencies. [exec] Stop. [exec] make: 1254-002 Cannot find a rule to create target depend from dependencies. [exec] Stop. [exec] make: make 1254-025 There must be an existing description file or specify a target. [exec] make: 1254-002 Cannot find a rule to create target test from dependencies. [exec] Stop. [exec] make: 1254-002 Cannot find a rule to create target install from dependencies. [exec] Stop.

1 0

Re: (ITS#6178) test048-syncrepl-multiproxy failed (exit 1)
by hyc＠symas.com 19 Jun '09

19 Jun '09

michael(a)stroeder.com wrote: > Full_Name: Michael Ströder > Version: HEAD > OS: openSUSE Linux 11.1 > URL: > Submission from: (NULL) (84.163.104.134) > > >>>>>> Starting test048-syncrepl-multiproxy ... > running defines.sh > Starting master slapd on TCP/IP port 9011... > Using ldapsearch to check that master slapd is running... > Using ldapadd to create the context prefix entry in the master... > Starting P1 slave slapd on TCP/IP port 9012... > Using ldapsearch to check that P1 slave slapd is running... > Starting R1 slave slapd on TCP/IP port 9013... > Using ldapsearch to check that R1 slave slapd is running... > 1> Using ldapadd to populate the master directory... > Waiting 3 seconds for syncrepl to receive changes... > 1< Comparing retrieved entries from master and P1 slave... > 1< Comparing retrieved entries from master and R1 slave... > 2> Stopping the provider, sleeping 7 seconds and restarting it... > Using ldapsearch to check that master slapd is running... > Using ldapmodify to modify master directory... > Waiting 3 seconds for syncrepl to receive changes... > 2< Comparing retrieved entries from master and P1 slave... > 2< Comparing retrieved entries from master and R1 slave... > 3> Stopping slaves to test recovery... > Modifying more entries on the master... > Restarting P1 slave... > Restarting R1 slave... > Waiting 3 seconds for syncrepl to receive changes... > 3< Comparing retrieved entries from master and P1 slave... > test failed - master and slave databases differ >>>>>> ./scripts/test048-syncrepl-multiproxy failed (exit 1) > make[2]: *** [bdb-mod] Error 1 > make[2]: Leaving directory `/usr/src/michael/openldap/HEAD/openldap/tests' > make[1]: *** [test] Error 2 > make[1]: Leaving directory `/usr/src/michael/openldap/HEAD/openldap/tests' > make: *** [test] Error 2 > > I think your SLEEP1 is too low, the default is 7 seconds, why are you using 3 seconds? -- -- 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#6177) bdb delete locking issue
by hyc＠symas.com 19 Jun '09

19 Jun '09

richton(a)nbcs.rutgers.edu wrote: > Howard has me experimenting with moving the lock from cache.c to delete.c. > With this experiment in place, I'm getting a failure with > test008/back-bdb. Under libumem, the crash is in bdb_search line 752. New fix in HEAD, please test. Thanks. -- -- 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#6181) slapo-unique: slaptest fails in case unique_uri is prepended the keywords "strict" or "ignore"
by daniel＠pluta.biz 19 Jun '09

19 Jun '09

Full_Name: Daniel Pluta Version: OPENLDAP_STABLE OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (91.12.203.84) Hi, from slapo-unique's manpage: "... It is possible to set strict checking for the uniqueness domain by prepending the keyword strict. ..." I've tried to use "unique_uri strict ldap:///....." and/or "unique_uri ignore ldap:///..." configuration syntax within slapd.conf. Both settings cause slaptest to fail with the error message: line 86: <strict> invalid ldap urilist my slapd.conf's line 86 looks (similar) to this one: unique_uri strict ldap:///dc=example,dc=com?uid?sub?(objectClass=account) The error message disapears and slapd starts up only in case the keywords "strict" and/or "ignore" get removed from slapd.conf again. After a quick look into unique's source I think the problem's cause seems to be located within/around the ConfigDriver function "unique_cf_uri", especially regarding the section "case LDAP_MOD_ADD:" if ( c->line ) rc = unique_new_domain ( &domain, c->line, c ); else rc = unique_new_domain ( &domain, c->argv[1], c ); I've added the following Debug statement Debug ( LDAP_DEBUG_TRACE, "c->line: %s\n", c->line, NULL, NULL ); just before the above condition. The output results in the following trace output: ==> unique_db_init line 86 (unique_uri strict ldap:///dc=example,dc=com?uid?sub?(objectClass=account)) c->line: (null) ==> unique_new_domain <strict> Because c->line is (null) only the else branch get's traversed... I don't understand exactly why. I've always used c->argv[n] (never used of c->line) in the past. Regarding the function: unique_new_domain( unique_domain **domainp, char *domain_spec, ConfigArgs *c ) if ( strncasecmp ( uri_start, "ignore ", STRLENOF( "ignore " ) ) == 0 ) { domain->ignore = 1; uri_start += STRLENOF( "ignore " ); } if ( strncasecmp ( uri_start, "strict ", STRLENOF( "strict " ) ) == 0 ) { domain->strict = 1; uri_start += STRLENOF( "strict " ); if ( !domain->ignore && strncasecmp ( uri_start, "ignore ", STRLENOF( "ignore " ) ) == 0 ) { domain->ignore = 1; uri_start += STRLENOF( "ignore " ); } } I'm not sure whether I've understand the design idea correctly but in my opinion the above strncasecmp-condition block shouldn't be located in this function. I would suggest to not handle the parsing and differentiation between "strict | ignore | ldap_uri" here. In my opinion this could also/better be handled in advance; perhaps directly within the ConfigDriver function by using the already parsed configuration tokens c->argv[n] instead of "c->line"? BTW: 1.) initially using "unique_uri ldap:///...." in slapd.conf 2.) converting slapd.conf into slapd.d-format 3.) Starting slapd 4.) Editing olcUniqueURI online via cn=config: inserting "strict" here work's fine (at least no error message is displayed ;-)) I've not tested whether the "strict" logic works correctly after these 4 steps. Cheers Daniel

1 0

(ITS#6180) section 3 manpages need RETURN VALUE section
by hyc＠OpenLDAP.org 18 Jun '09

18 Jun '09

Full_Name: Howard Chu Version: 2.4 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (76.91.220.157) Submitted by: hyc The return value from libldap/liblber functions is described in the DESCRIPTION section; in most manpages this text is in its own RETURN VALUE section. Even though the information is there, without the header it is easy to miss.

1 0

Re: (ITS#6177) bdb delete locking issue
by richton＠nbcs.rutgers.edu 18 Jun '09

18 Jun '09

Howard has me experimenting with moving the lock from cache.c to delete.c. With this experiment in place, I'm getting a failure with test008/back-bdb. Under libumem, the crash is in bdb_search line 752. I see that rs->sr_un.sru_search.r_entry = 0xbaddcafebaddcafe -- uninitialized per libumem -- is being used as an argument to is_entry_subentry(). Backtrace: https://www.nbcs.rutgers.edu/~richton/test008-bt-200906181020.txt -d -1: https://www.nbcs.rutgers.edu/~richton/test008-slapdlog-200906181020.txt

1 0

Re: (ITS#6173) Error while making
by hyc＠symas.com 18 Jun '09

18 Jun '09

Usage questions belong on the openldap-software mailing list. There is no bug here, this ITS will be closed. Bipin.Nair(a)iflexsolutions.com wrote: > This is a multi-part message in MIME format. > > ------_=_NextPart_001_01C9EFB5.22156E9E > Content-Type: text/plain; > charset="iso-8859-1" > Content-Transfer-Encoding: quoted-printable > > Thanks. > Do you think that the OpenSSL and Berkley DB version also should change = > when I go with a upgraded OpenLDAP version? > =20 > Also,is it mandatory to have Cyrus sasl also installed prior to = > OpenLDAP? -- -- 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#6179) ACL expand style requres dn.regex in what clause
by rein＠OpenLDAP.org 18 Jun '09

18 Jun '09

Full_Name: Rein Tollevik Version: 2.4.16 OS: Irrelevant URL: Submission from: (NULL) (2a01:600:0:1:21c:23ff:feab:61cd) Submitted by: rein Using the expand style (as in "set.expand") in an ACL requires the <what> clause to include a dn.regex style. This is far too restrictive now that the other dn.* styles and attrs val.regex also provides submatches that can be expanded. The test could be extended to also include these cases, but should in that case never fail since there is always an implicit dn.regex=^.*$ <what> present when no DN is specified. So, I'd prefer to remove this check, as in the patch at the end. As of now I use "set.regex=" and overlook the deprecated warning that gives me... Rein Tollevik Basefarm AS --- aclparse.c 15 May 2009 11:45:31 +0200 1.2 +++ aclparse.c 18 Jun 2009 16:21:02 +0200 @@ -851,16 +851,6 @@ } } - /* expand in <who> needs regex in <what> */ - if ( ( sty == ACL_STYLE_EXPAND || expand ) - && a->acl_dn_style != ACL_STYLE_REGEX ) - { - Debug( LDAP_DEBUG_CONFIG | LDAP_DEBUG_ACL, "%s: line %d: \"expand\" style " - "or modifier used in conjunction with a non-regex <what> clause.\n", - fname, lineno, 0 ); - goto fail; - } - if ( strncasecmp( left, "real", STRLENOF( "real" ) ) == 0 ) { is_realdn = 1; bdn = &b->a_realdn;

1 0

Re: (ITS#6177) bdb delete locking issue
by richton＠nbcs.rutgers.edu 18 Jun '09

18 Jun '09

This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---559023410-851401618-1245331022=:1022 Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE On Thu, 18 Jun 2009, Michael Str=F6der wrote: > richton(a)nbcs.rutgers.edu wrote: >> 2.4.17 prerelease testing revealed SEGVs in test039's slapd.1. > > Maybe that's related to ITS#6170 I've filed? If I'm reading correctly, 6170 and 5733 are connection handling? But then= =20 again, we're talking some sort of corruption, it could manifest itself=20 many ways... ---559023410-851401618-1245331022=:1022--

1 0

Re: (ITS#6178) test048-syncrepl-multiproxy failed (exit 1)
by michael＠stroeder.com 18 Jun '09

18 Jun '09

You can download testrun/ with SLAPD_DEBUG=16389 here: http://www.stroeder.com/temp/openldap/its6178-test048-testrun.tar.gz

1 0

(ITS#6178) test048-syncrepl-multiproxy failed (exit 1)
by michael＠stroeder.com 18 Jun '09

18 Jun '09

Full_Name: Michael Ströder Version: HEAD OS: openSUSE Linux 11.1 URL: Submission from: (NULL) (84.163.104.134) >>>>> Starting test048-syncrepl-multiproxy ... running defines.sh Starting master slapd on TCP/IP port 9011... Using ldapsearch to check that master slapd is running... Using ldapadd to create the context prefix entry in the master... Starting P1 slave slapd on TCP/IP port 9012... Using ldapsearch to check that P1 slave slapd is running... Starting R1 slave slapd on TCP/IP port 9013... Using ldapsearch to check that R1 slave slapd is running... 1 > Using ldapadd to populate the master directory... Waiting 3 seconds for syncrepl to receive changes... 1 < Comparing retrieved entries from master and P1 slave... 1 < Comparing retrieved entries from master and R1 slave... 2 > Stopping the provider, sleeping 7 seconds and restarting it... Using ldapsearch to check that master slapd is running... Using ldapmodify to modify master directory... Waiting 3 seconds for syncrepl to receive changes... 2 < Comparing retrieved entries from master and P1 slave... 2 < Comparing retrieved entries from master and R1 slave... 3 > Stopping slaves to test recovery... Modifying more entries on the master... Restarting P1 slave... Restarting R1 slave... Waiting 3 seconds for syncrepl to receive changes... 3 < Comparing retrieved entries from master and P1 slave... test failed - master and slave databases differ >>>>> ./scripts/test048-syncrepl-multiproxy failed (exit 1) make[2]: *** [bdb-mod] Error 1 make[2]: Leaving directory `/usr/src/michael/openldap/HEAD/openldap/tests' make[1]: *** [test] Error 2 make[1]: Leaving directory `/usr/src/michael/openldap/HEAD/openldap/tests' make: *** [test] Error 2

1 0

Re: (ITS#6177) bdb delete locking issue
by michael＠stroeder.com 18 Jun '09

18 Jun '09

richton(a)nbcs.rutgers.edu wrote: > 2.4.17 prerelease testing revealed SEGVs in test039's slapd.1. Maybe that's related to ITS#6170 I've filed? Ciao, Michael.

1 0

Re: (ITS#6173) Error while making
by mkassawara＠gmail.com 18 Jun '09

18 Jun '09

I recommend upgrading both BDB and OpenSSL. You might want to check out the following sites which offer fairly recent precompiled packages of open source software to save yourself a few headaches on AIX... http://pware.hvcc.edu http://www.perzl.org/aix OpenLDAP does not require SASL, but you might need it depending on how you plan to deploy the former. On Jun 17, 2009, at 7:34 PM, <Bipin.Nair(a)iflexsolutions.com> wrote: > Thanks. > Do you think that the OpenSSL and Berkley DB version also should > change when I go with a upgraded OpenLDAP version? > > Also,is it mandatory to have Cyrus sasl also installed prior to > OpenLDAP? > > > > From: mkassawara(a)gmail.com on behalf of Matt Kassawara > Sent: Wed 6/17/2009 09:30 > To: Bipin Nair-SJR > Cc: openldap-its(a)openldap.org > Subject: Re: (ITS#6173) Error while making > > You are using a deprecated version of OpenLDAP. Consider upgrading > to a recent version... preferrably 2.4. > > On Wed, Jun 17, 2009 at 4:42 AM, <bipin.nair(a)iflexsolutions.com> > wrote: > Full_Name: Bipin > Version: OpenLDAP2.2.29 > OS: AIX 5.3 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (203.127.116.93) > > > Hi, > > While trying to install OpenLDAP 2.2.29 ,I getting the following > error during > the 'make' step. > > > --------------------------------------------------------------------- > Notes:- > > 1)I have installed OpenSSL 0.9.7 and Berkley DB 4.5.20 > > 2)Also,the follwing variables are set > CPPFLAGS > LDFLAGS > LIBPATH > > 3)THe follwoing commands were used as steps to install Openldap > cd openldap-2.2.29 > ./configure --enable-ldbm > make depend > make (During this step it fails) > > ------------------------------------------------------------------- > > > acl.c:85: error: conflicting types for 'acl_get' > /usr/include/sys/access.h:86: error: previous declaration of > 'acl_get' was here > make: 1254-004 The error code from the last command is 1. > > > Stop. > make: 1254-004 The error code from the last command is 2. > > > Stop. > make: 1254-004 The error code from the last command is 2. > > > Stop. > > > Please help with this issue. > > Thanks. > > > > DISCLAIMER: > This message contains privileged and confidential information and is > intended only for an individual named. If you are not the intended > recipient, you should not disseminate, distribute, store, print, > copy or deliver this message. Please notify the sender immediately > by e-mail if you have received this e-mail by mistake and delete > this e-mail from your system. E-mail transmission cannot be > guaranteed to be secure or error-free as information could be > intercepted, corrupted, lost, destroyed, arrive late or incomplete > or contain viruses. The sender, therefore, does not accept liability > for any errors or omissions in the contents of this message which > arise as a result of e-mail transmission. If verification is > required, please request a hard-copy version. >

1 0

RE: (ITS#6173) Error while making
by Bipin.Nair＠iflexsolutions.com 18 Jun '09

18 Jun '09

This is a multi-part message in MIME format. ------_=_NextPart_001_01C9EFB5.22156E9E Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thanks. Do you think that the OpenSSL and Berkley DB version also should change = when I go with a upgraded OpenLDAP version? =20 Also,is it mandatory to have Cyrus sasl also installed prior to = OpenLDAP? =20 =20 ________________________________ From: mkassawara(a)gmail.com on behalf of Matt Kassawara Sent: Wed 6/17/2009 09:30 To: Bipin Nair-SJR Cc: openldap-its(a)openldap.org Subject: Re: (ITS#6173) Error while making You are using a deprecated version of OpenLDAP. Consider upgrading to a = recent version... preferrably 2.4. On Wed, Jun 17, 2009 at 4:42 AM, <bipin.nair(a)iflexsolutions.com> wrote: Full_Name: Bipin Version: OpenLDAP2.2.29 OS: AIX 5.3 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (203.127.116.93) =09 =09 Hi, =09 While trying to install OpenLDAP 2.2.29 ,I getting the following error = during the 'make' step. =09 =09 --------------------------------------------------------------------- Notes:- =09 1)I have installed OpenSSL 0.9.7 and Berkley DB 4.5.20 =09 2)Also,the follwing variables are set CPPFLAGS LDFLAGS LIBPATH =09 3)THe follwoing commands were used as steps to install Openldap cd openldap-2.2.29 ./configure --enable-ldbm make depend make (During this step it fails) =09 ------------------------------------------------------------------- =09 =09 acl.c:85: error: conflicting types for 'acl_get' /usr/include/sys/access.h:86: error: previous declaration of 'acl_get' = was here make: 1254-004 The error code from the last command is 1. =09 =09 Stop. make: 1254-004 The error code from the last command is 2. =09 =09 Stop. make: 1254-004 The error code from the last command is 2. =09 =09 Stop. =09 =09 Please help with this issue. =09 Thanks. =09 =09 DISCLAIMER: This message contains privileged and confidential information and is = intended only for an individual named. If you are not the intended = recipient, you should not disseminate, distribute, store, print, copy or = deliver this message. Please notify the sender immediately by e-mail if = you have received this e-mail by mistake and delete this e-mail from = your system. E-mail transmission cannot be guaranteed to be secure or = error-free as information could be intercepted, corrupted, lost, = destroyed, arrive late or incomplete or contain viruses. The sender, = therefore, does not accept liability for any errors or omissions in the = contents of this message which arise as a result of e-mail transmission. = If verification is required, please request a hard-copy version. ------_=_NextPart_001_01C9EFB5.22156E9E Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <HTML dir=3Dltr><HEAD>=0A= <META http-equiv=3DContent-Type content=3D"text/html; charset=3Dunicode">=0A= <META content=3D"MSHTML 6.00.2900.3492" name=3DGENERATOR></HEAD>=0A= <BODY>=0A= <DIV id=3DidOWAReplyText64405 dir=3Dltr>=0A= <DIV dir=3Dltr>Thanks.</DIV>=0A= <DIV dir=3Dltr>Do you think that the = OpenSSL and Berkley DB version also should change when I go with a = upgraded OpenLDAP version?</DIV>=0A= <DIV dir=3Dltr> </DIV>=0A= <DIV dir=3Dltr>Also,is it mandatory = to have Cyrus sasl also installed prior to OpenLDAP?</DIV>=0A= <DIV dir=3Dltr> </DIV>=0A= <DIV dir=3Dltr> </DIV></DIV>=0A= <DIV dir=3Dltr> =0A= <HR tabIndex=3D-1>=0A= From: mkassawara(a)gmail.com on behalf = of Matt Kassawara Sent: Wed 6/17/2009 09:30 To: = Bipin Nair-SJR Cc: = openldap-its(a)openldap.org Subject: Re: (ITS#6173) Error while = making </DIV>=0A= <DIV>You are using a deprecated version of OpenLDAP.  Consider = upgrading to a recent version... preferrably 2.4. =0A= <DIV class=3Dgmail_quote>On Wed, Jun 17, 2009 at 4:42 AM, <<A = href=3D"mailto:bipin.nair@iflexsolutions.com">bipin.nair(a)iflexsolutions.c= om</A>> wrote: =0A= <BLOCKQUOTE class=3Dgmail_quote style=3D"PADDING-LEFT: 1ex; MARGIN: 0px = 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">Full_Name: Bipin Version: = OpenLDAP2.2.29 OS: AIX 5.3 URL: <A = href=3D"ftp://ftp.openldap.org/incoming/" = target=3D_blank>ftp://ftp.openldap.org/incoming/</A> Submission from: = (NULL) (203.127.116.93) Hi, While trying to install = OpenLDAP 2.2.29 ,I getting the following error during the 'make' = step. --------------------------------------------------------= ------------- Notes:- 1)I have installed OpenSSL 0.9.7 and = Berkley DB 4.5.20 2)Also,the follwing variables are = set CPPFLAGS LDFLAGS LIBPATH 3)THe follwoing commands = were used as steps to install Openldap cd = openldap-2.2.29 ./configure --enable-ldbm make depend make = (During this step it = fails) -----------------------------------------------------------= -------- acl.c:85: error: conflicting types for = 'acl_get' /usr/include/sys/access.h:86: error: previous declaration = of 'acl_get' was here make: 1254-004 The error code from the last = command is 1. Stop. make: 1254-004 The error code from the = last command is 2. Stop. make: 1254-004 The error code = from the last command is 2. Stop. Please help with = this = issue. Thanks. </BLOCKQUOTE></DIV> </DIV>DISCL= AIMER: This message contains privileged and confidential information = and is intended only for an individual named. If you are not the = intended recipient, you should not disseminate, distribute, store, = print, copy or deliver this message. Please notify the sender = immediately by e-mail if you have received this e-mail by mistake and = delete this e-mail from your system. E-mail transmission cannot be = guaranteed to be secure or error-free as information could be = intercepted, corrupted, lost, destroyed, arrive late or incomplete or = contain viruses. The sender, therefore, does not accept liability for = any errors or omissions in the contents of this message which arise as a = result of e-mail transmission. If verification is required, please = request a hard-copy version.</BODY></HTML> ------_=_NextPart_001_01C9EFB5.22156E9E--

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs