- openldap-bugs - openldap.org

Re: (ITS#6191) test022-ppolicy failed (exit 21)
by hyc＠symas.com 01 Jul '09

01 Jul '09

Michael Ströder wrote: > Howard Chu wrote: >> michael(a)stroeder.com wrote: >>> Full_Name: Michael Ströder >>> Version: HEAD synced now >>> OS: openSUSE Linux 11.1 >>> URL: ftp://ftp.openldap.org/incoming/ >>> Submission from: (NULL) (84.163.60.129) >> >>> Setting up policy state forwarding test... >>> Starting slapd consumer on TCP/IP port 9012... >>> Configuring syncprov on provider... >>> Using ldapsearch to check that slapd is running... >>> Waiting 5 seconds for slapd to start... >>> Configuring syncrepl on consumer... >>> ldapmodify failed (21)! >>>>>>>> ./scripts/test022-ppolicy failed (exit 21) >>> make[2]: *** [bdb-mod] Error 21 >>> 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 >> >> Please provide a tarball of the testrun directory. > > Here it is: > http://www.stroeder.com/temp/openldap/its-6191-testrun-test022-ppolicy_fail… Looks like you don't have back-ldap enabled in your slapd. What were your configure flags? -- -- 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#6191) test022-ppolicy failed (exit 21)
by michael＠stroeder.com 01 Jul '09

01 Jul '09

Howard Chu wrote: > michael(a)stroeder.com wrote: >> Full_Name: Michael Ströder >> Version: HEAD synced now >> OS: openSUSE Linux 11.1 >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (84.163.60.129) > >> Setting up policy state forwarding test... >> Starting slapd consumer on TCP/IP port 9012... >> Configuring syncprov on provider... >> Using ldapsearch to check that slapd is running... >> Waiting 5 seconds for slapd to start... >> Configuring syncrepl on consumer... >> ldapmodify failed (21)! >>>>>>> ./scripts/test022-ppolicy failed (exit 21) >> make[2]: *** [bdb-mod] Error 21 >> 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 > > Please provide a tarball of the testrun directory. Here it is: http://www.stroeder.com/temp/openldap/its-6191-testrun-test022-ppolicy_fail… Ciao, Michael.

1 0

Re: (ITS#6191) test022-ppolicy failed (exit 21)
by hyc＠symas.com 01 Jul '09

01 Jul '09

michael(a)stroeder.com wrote: > Full_Name: Michael Ströder > Version: HEAD synced now > OS: openSUSE Linux 11.1 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (84.163.60.129) > Setting up policy state forwarding test... > Starting slapd consumer on TCP/IP port 9012... > Configuring syncprov on provider... > Using ldapsearch to check that slapd is running... > Waiting 5 seconds for slapd to start... > Configuring syncrepl on consumer... > ldapmodify failed (21)! >>>>>> ./scripts/test022-ppolicy failed (exit 21) > make[2]: *** [bdb-mod] Error 21 > 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 Please provide a tarball of the testrun directory. -- -- 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#6191) test022-ppolicy failed (exit 21)
by michael＠stroeder.com 01 Jul '09

01 Jul '09

Full_Name: Michael Ströder Version: HEAD synced now OS: openSUSE Linux 11.1 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (84.163.60.129) >>>>> Starting test022-ppolicy ... running defines.sh Starting slapd on TCP/IP port 9011... Using ldapsearch to check that slapd is running... Using ldapadd to populate the database... Testing account lockout... Waiting 20 seconds for lockout to reset... Testing password expiration Waiting 20 seconds for password to expire... Resetting password to clear expired status Filling password history... Testing password history... Testing forced reset... Clearing forced reset... Testing Safe modify... Testing length requirement... Testing hashed length requirement... Testing multiple password add/modify checks... Setting up policy state forwarding test... Starting slapd consumer on TCP/IP port 9012... Configuring syncprov on provider... Using ldapsearch to check that slapd is running... Waiting 5 seconds for slapd to start... Configuring syncrepl on consumer... ldapmodify failed (21)! >>>>> ./scripts/test022-ppolicy failed (exit 21) make[2]: *** [bdb-mod] Error 21 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#6089) connection_destroy() c->c_writers == 0 assertion failure
by jwm＠horde.net 30 Jun '09

30 Jun '09

On Tue, Jun 30, 2009 at 06:05:09PM -0700, Howard Chu wrote: > John Morrissey wrote: > > It's happened once or twice, but it hasn't had much time since this is > > the same machine I just got done chasing the i386 heap fragmentation on. > > Our backtrace/core/BDB harness is still on this slapd, so we should have > > information if it happens again. > > I was able to reproduce this today, a fix is now in HEAD. Please test, > thanks. Sorry Howard, we've retired our i386 machines and haven't seen this with RE24 as of 20090511 on amd64. john -- John Morrissey _o /\ ---- __o jwm(a)horde.net _-< \_ / \ ---- < \, www.horde.net/ __(_)/_(_)________/ \_______(_) /_(_)__

1 0

Re: (ITS#6089) connection_destroy() c->c_writers == 0 assertion failure
by hyc＠symas.com 30 Jun '09

30 Jun '09

John Morrissey wrote: > It's happened once or twice, but it hasn't had much time since this is the > same machine I just got done chasing the i386 heap fragmentation on. Our > backtrace/core/BDB harness is still on this slapd, so we should have > information if it happens again. I was able to reproduce this today, a fix is now 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#6190) back-meta tls start only works when set before any target specification
by stephan.duehr＠dass-it.de 30 Jun '09

30 Jun '09

Full_Name: Stephan Duehr Version: 2.4.16 OS: SLES 10 SP2 URL: Submission from: (NULL) (84.44.166.251) I specified tls start below each target specification and did not find any STARTTLS in the targets log, running at loglevel 256. man slapd-meta says: tls {[try-]start|[try-]propagate} execute the StartTLS extended operation when the connection is initialized; only works if the URI directive protocol scheme is not ldaps://. propagate issues the StartTLS operation only if the original connection did. The try- prefix instructs the proxy to continue operations if the StartTLS operation failed; its use is highly deprecated. If set before any target specification, it affects all targets, unless overridden by any per-target directive. So it should work when set for a target. I verified the behavior by removing start tls before any target specfication and setting it below each target, which resulted in not STARTTLS being sent again.

1 0

Re: (ITS#6084) ppolicy should allow scheduled password expiration
by hyc＠symas.com 30 Jun '09

30 Jun '09

Guillaume Rousse wrote: > Howard Chu a écrit : >> Since the ppolicy module's behavior is dictated by the Behera draft, any >> suggestions for changes in this area should probably first be raised on >> the ietf-ldapext mailing list. > Right, but openldap implementation already have extension, such > pwdCheckModule. Additional extension could be implemented, before > getting standardized. > > Also, the ietf-ldapext seems to be an highly-technical list, and I don't > feel confortable enough to post this kind of request directly there. > Discussing various limitations of ppolicy among openldap users first > would probably allow openldap core team to suggest a more polished > extension request themselves. The draft doesn't say anything about setting pwdAccountLockedTime to a value in the future; since it doesn't preclude it I've fixed up the code to handle this case. However, it's not a good solution for your purpose, since the pwdAccountLockedTime value is automatically replaced with the current time if too many Bind failures occur, and it's automatically deleted when a password is changed. We'll leave this in HEAD on an experimental basis for now, until a real solution is spec'd out. -- -- 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#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 27 Jun '09

27 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 23 Jun '09

23 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 23 Jun '09

23 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 22 Jun '09

22 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 22 Jun '09

22 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 22 Jun '09

22 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 22 Jun '09

22 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 20 Jun '09

20 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 18 Jun '09

18 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 18 Jun '09

18 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 18 Jun '09

18 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 17 Jun '09

17 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 17 Jun '09

17 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

Re: (ITS#6176) cachesize vs dncachesize
by hyc＠symas.com 17 Jun '09

17 Jun '09

h.b.furuseth(a)usit.uio.no wrote: > Full_Name: Hallvard B Furuseth > Version: 2.4.16 > OS: > URL: http://www.openldap.org/lists/openldap-software/200906/msg00021.html > Submission from: (NULL) (129.240.6.233) > Submitted by: hallvard > > > The referred openldap-software message says: >> From: Howard Chu<hyc(a)symas.com> >> >> dncachesize must always be>= cachesize > > This is not documented, neither in manpage nor admin guide. > > Also slapd should preferably catch attempts to set them wrong, and > either adjust them or fail the change. That's so for many config > options, but more important for interactions between options. The details here are unimportant. Since entry cache items hang off of dncache items, the only consequence of a "wrong" configuration here is that the entry cache could only ever grow to the size of the dncache. At any rate, the code has been patched to set dncachesize >= cachesize, and the manpage updated correspondingly, but there's no critical problem without this patch. -- -- 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#6177) bdb delete locking issue
by richton＠nbcs.rutgers.edu 17 Jun '09

17 Jun '09

Full_Name: Aaron Richton Version: HEAD OS: Solaris 9 URL: https://www.nbcs.rutgers.edu/~richton/test039-bt-200906170640.txt Submission from: (NULL) (67.85.182.223) 2.4.17 prerelease testing revealed SEGVs in test039's slapd.1. libumem revealed a deadbeef (previously freed) ei. umem transaction logs, slapd logs, and logical deduction are currently leaning toward an issue with deletions. umem transaction log of ei: https://www.nbcs.rutgers.edu/~richton/test039-umem-200906170640.txt -d -1 (26MB): https://www.nbcs.rutgers.edu/~richton/test039-slapdlog-200906170640.txt

1 0

(ITS#6176) cachesize vs dncachesize
by h.b.furuseth＠usit.uio.no 17 Jun '09

17 Jun '09

Full_Name: Hallvard B Furuseth Version: 2.4.16 OS: URL: http://www.openldap.org/lists/openldap-software/200906/msg00021.html Submission from: (NULL) (129.240.6.233) Submitted by: hallvard The referred openldap-software message says: > From: Howard Chu <hyc(a)symas.com> > > dncachesize must always be >= cachesize This is not documented, neither in manpage nor admin guide. Also slapd should preferably catch attempts to set them wrong, and either adjust them or fail the change. That's so for many config options, but more important for interactions between options. If that's fixed by adjusting the input values, then cachesize configuration can be simplified for users: Given cachesize, calculate the recommended defaults for the other cache size variables (idlcachesize, dncachesize, cachefree). Keep the real variables used by the backend separate, copied/defaulted from input variables that are set by cn=config and not defaulted.

1 0

Re: (ITS#6126) test054-syncreplication-parallel-load failed: producer and consumer databases differ
by hyc＠symas.com 17 Jun '09

17 Jun '09

Michael Ströder wrote: > hyc(a)symas.com wrote: >> michael(a)stroeder.com wrote: >>> I cannot reproduce it all the time. >> >> Can you add SYNC to your debug level and get the logs from one of these incidents? > > What would be the best place to set the debug level when running > test054? And only set it to "loglevel sync" or also other flags? set the SLAPD_DEBUG environment variable, the default value is 5. Add sync to the default... -- -- 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#6175) Slapd crashes when using accesslog
by michael＠stroeder.com 17 Jun '09

17 Jun '09

openldap-bugs(a)gleim.com wrote: > Full_Name: Ben Goldsbury > Version: 2.4.11 > OS: Debian Lenny running under Xen > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (209.208.68.3) > > Slapd dies whenever the accesslog is enabled with the following BT. Please let > me know what additional information you might need. I am also in #openldap as > bpgoldsb. Does this also happen when running recent OpenLDAP release 2.4.16 built from source? Ciao, Michael.

1 0

Re: (ITS#6126) test054-syncreplication-parallel-load failed: producer and consumer databases differ
by michael＠stroeder.com 17 Jun '09

17 Jun '09

hyc(a)symas.com wrote: > michael(a)stroeder.com wrote: >> I cannot reproduce it all the time. > > Can you add SYNC to your debug level and get the logs from one of these incidents? What would be the best place to set the debug level when running test054? And only set it to "loglevel sync" or also other flags? Ciao, Michael.

1 0

(ITS#6175) Slapd crashes when using accesslog
by openldap-bugs＠gleim.com 17 Jun '09

17 Jun '09

Full_Name: Ben Goldsbury Version: 2.4.11 OS: Debian Lenny running under Xen URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (209.208.68.3) Slapd dies whenever the accesslog is enabled with the following BT. Please let me know what additional information you might need. I am also in #openldap as bpgoldsb. #0 0x00002b4ae5a45552 in ber_dupbv_x () from /usr/lib/liblber-2.4.so.2 #1 0x0000000000439a2e in attr_valadd (a=0x8ac4f0, vals=0x48, nvals=0x0, nn=1) at /home/devel/openldap/build-area/openldap-2.4.11/servers/slapd/attr.c:423 #2 0x00002b4aea39bf8d in accesslog_entry (op=0x407ffde0, rs=0x407fff50, logop=<value optimized out>, op2=0x4067f1d0) at /home/devel/openldap/build-area/openldap-2.4.11/servers/slapd/overlays/accesslog.c:1200 #3 0x00002b4aea39c40f in accesslog_response (op=0x407ffde0, rs=0x407fff50) at /home/devel/openldap/build-area/openldap-2.4.11/servers/slapd/overlays/accesslog.c:1363 #4 0x00000000004907a8 in over_back_response (op=0x407ffde0, rs=0x407fff50) at /home/devel/openldap/build-area/openldap-2.4.11/servers/slapd/backover.c:235 #5 0x00000000004402ef in slap_response_play (op=0x407ffde0, rs=0x407fff50) at /home/devel/openldap/build-area/openldap-2.4.11/servers/slapd/result.c:307 #6 0x0000000000442e0d in send_ldap_response (op=0x87b7e0, rs=0x48) at /home/devel/openldap/build-area/openldap-2.4.11/servers/slapd/result.c:381 #7 0x00000000004439ab in slap_send_ldap_result (op=0x407ffde0, rs=0x407fff50) at /home/devel/openldap/build-area/openldap-2.4.11/servers/slapd/result.c:642 #8 0x00002b4ae9f5e3b3 in bdb_search (op=0x407ffde0, rs=0x407fff50) at /home/devel/openldap/build-area/openldap-2.4.11/servers/slapd/back-bdb/search.c:928 #9 0x0000000000490a07 in overlay_op_walk (op=0x407ffde0, rs=0x407fff50, which=op_search, oi=0x7f3100, on=0x0) at /home/devel/openldap/build-area/openldap-2.4.11/servers/slapd/backover.c:646 #10 0x0000000000491473 in over_op_func (op=0x407ffde0, rs=0x2b4ae763ca50, which=op_bind) at /home/devel/openldap/build-area/openldap-2.4.11/servers/slapd/backover.c:698 #11 0x00002b4aea1903f9 in syncprov_findcsn (op=<value optimized out>, mode=<value optimized out>) at /home/devel/openldap/build-area/openldap-2.4.11/servers/slapd/overlays/syncprov.c:704 #12 0x00002b4aea191a7e in syncprov_db_otask (ptr=0x87b7e0) at /home/devel/openldap/build-area/openldap-2.4.11/servers/slapd/overlays/syncprov.c:2672 #13 0x00002b4ae70d8fc7 in start_thread () from /lib/libpthread.so.0 #14 0x00002b4ae73bd5ad in clone () from /lib/libc.so.6 #15 0x0000000000000000 in ?? () Relevant part of slapd.conf: moduleload accesslog overlay accesslog logdb cn=log logops all # Scan the accesslog DB every day # Purge entries older than 7 days logpurge 07+00:00 01+00:00 database bdb suffix cn=log directory /var/lib/ldap/accesslog/ # Allow manager to read the Monitor information access to dn.subtree="cn=log" by dn.exact="cn=Manager,dc=example,dc=com" read by * none

1 0

Re: (ITS#6173) Error while making
by battery＠writeme.com 17 Jun '09

17 Jun '09

--001e680f175823722e046c8c2226 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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. > > --001e680f175823722e046c8c2226 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable You are using a deprecated version of OpenLDAP. =A0Consider upgrading to a = recent version... preferrably 2.4. <div class=3D"gmail_quote">On Wed= , Jun 17, 2009 at 4:42 AM, <<a href=3D"mailto:bipin.n= air(a)iflexsolutions.com">bipin.nair(a)iflexsolutions.com</a>> wrote:= <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex;">Full_Name: Bipin Version: OpenLDAP2.2.29 OS: AIX 5.3 URL: <a href=3D"ftp://ftp.openldap.org/incoming/" target=3D"_blank">ftp://f= tp.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 duri= ng 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&#= 39; 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> --001e680f175823722e046c8c2226--

1 0

(ITS#6174) Permanent high CPU Load with Multimaster
by Frank.Offermanns＠caseris.de 17 Jun '09

17 Jun '09

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. 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) I also tested the original/downloadable 2.4.16 with a Windows Cygwin build and a Ubuntu build. But i had similar problems with each build. I have not tested the latest Version with Ubuntu or Cygwin. I tried to compile it with Ubuntu 9.04 to check if this problem is still OS independent but got this error when calling configure (CPPFLAGS=-D_GNU_SOURCE ./configure --enable-hdb=mod --enable-bdb=mod --enable-modules=yes --enable-syncprov=mod): "bash: ./configure: /bin/sh^M: bad interpreter: No such file or directory" Here is my slapd.conf which i converted with "slapdtest -f slapd.conf -F slapd" I am not interested in configuration replication. I know, that for security reasons i should not take the superuser for the replication, but i did this to simplify my tests. Personcaesar and ConfigObjects are selfdefined shemas. # # See slapd.conf(5) for details on configuration options. # This file should NOT be world readable. # ucdata-path ./ucdata include ./schema/core.schema include ./schema/cosine.schema include ./schema/Personcaesar.schema include ./schema/ConfigObjects.schema loglevel 0 # Define global ACLs to disable default read access. # Do not enable referrals until AFTER you have a working directory # service AND an understanding of referrals. #referral ldap:/root.openldap.org pidfile ./run/slapd.pid argsfile ./run/slapd.args # Load dynamic backend modules: # modulepath ./libexec/openldap # moduleload back_bdb.la # moduleload back_ldap.la # moduleload back_ldbm.la # moduleload back_passwd.la # moduleload back_shell.la # Sample security restrictions # Require integrity protection (prevent hijacking) # Require 112-bit (3DES or better) encryption for updates # Require 63-bit encryption for simple bind # security ssf=1 update_ssf=112 simple_bind=64 # Sample access control policy: # Root DSE: allow anyone to read it # Subschema (sub)entry DSE: allow anyone to read it # Other DSEs: # Allow self write access # Allow authenticated users read access # Allow anonymous users to authenticate # Directives needed to implement policy: # access to dn.base="" by * read # access to dn.base="cn=Subschema" by * read # access to * # by self write # by users read # by anonymous auth access to * by dn.one="ou=Admins,o=caesar" write by * read ServerID 1 "ldap://CAS-WS090309.ub2.cae.local" ServerID 2 "ldap://franktestxp.ub2.cae.local" # # if no access controls are present, the default policy # allows anyone and everyone to read anything but restricts # updates to rootdn. (e.g., "access to * by * read") # # rootdn can always read and write EVERYTHING! ####################################################################### database config rootdn cn=config rootpw config ####################################################################### # BDB database definitions ####################################################################### database hdb cachesize 10000 idlcachesize 30000 suffix "" checkpoint 1024 5 rootdn "cn=Administrator,o=caesar" # Cleartext passwords, especially for the rootdn, should # be avoid. See slappasswd(8) and slapd.conf(5) for details. # Use of strong authentication encouraged. rootpw secret # The database directory MUST exist prior to running slapd AND # should only be accessible by the slapd and slap tools. # Mode 700 recommended. directory "c:/all/data" dbconfig set_cachesize 0 400000000 1 dbconfig set_flags DB_LOG_AUTOREMOVE dbconfig set_lg_regionmax 1048576 dbconfig set_lg_max 10485760 dbconfig set_lg_bsize 2097152 # Indices to maintain index sn pres,eq index cn pres,eq,sub index MasterApp pres,eq index RightVoice pres,eq index DCOMServer pres,eq index ExtensionSMS pres,eq index ExtensionFax pres,eq,sub index ExtensionVoice pres,eq,sub index ExtensionCTI pres,eq index Deleted pres,eq index GUID pres,eq index CTIServerName pres,eq,sub index LastSyncUser pres,eq index ApplicationPhoneNr pres,eq,sub index NetDialLoginName pres,eq index email pres,eq index FullExtensionVoice pres,eq,sub index FullExtensionFax pres,eq,sub index FullExtensionSMS pres,eq index FullName pres,eq index PersonalID pres,eq index entryUUID eq index entryCSN eq index objectClass eq overlay syncprov syncprov-checkpoint 1000 60 syncprov-sessionlog 10000 syncrepl rid=001 provider="ldap://CAS-WS090309.ub2.cae.local" searchbase="o=caesar" type=refreshAndPersist retry="5 3 15 +" binddn="cn=Administrator,o=caesar" bindmethod=simple credentials="secret" syncrepl rid=002 provider="ldap://franktestxp.ub2.cae.local" searchbase="o=caesar" type=refreshAndPersist retry="5 3 15 +" binddn="cn=Administrator,o=caesar" bindmethod=simple credentials="secret" MirrorMode On sizelimit size.soft=100 size.hard=1000 size.prtotal=unlimited

1 0

(ITS#6173) Error while making
by bipin.nair＠iflexsolutions.com 17 Jun '09

17 Jun '09

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.

1 0

Re: (ITS#6094) test054 doesn't replicate an entry
by dieter＠dkluenter.de 17 Jun '09

17 Jun '09

Howard Chu <hyc(a)symas.com> writes: > dieter(a)dkluenter.de wrote: >> Full_Name: Dieter Kluenter >> Version: 2.4.16 >> OS: Linux x86_64 >> URL: http://dkluenter.de/download/dkluenter_test054.tgz >> Submission from: (NULL) (87.154.44.82) > >> test054 doesn't replicate the entry dn: ou=3DInformation Technolgy >> Devision,ou=3Dpeople,dc=3Dexample,dc=3Dcom >> A tar archive containing the files >> server1.flt, server2.flt, server1.log, server4.log >> can be downloaded from the below URL > > To aid in reproducing this problem, please provide specific details on > your platform: OS version, CPU architecture, and whether single core > or multi-core. CPU model # may be helpful for comparison purposes. OS: openSUSE-11.1 Hardware Class: cpu Arch: X86-64 Vendor: "AuthenticAMD" Model: 15.31.0 "AMD Athlon(tm) 64 Processor 3000+" Features: fpu,vme,de,pse,tsc,msr,pae,mce,cx8,apic,sep,mtrr,pge,mca,cmov,pat= ,pse36,clflush,mmx,fxsr,sse,sse2,syscall,nx,mmxext,fxsr_opt,lm,3dnowext,3dn= ow,up,rep_good,nopl,lahf_lm Clock: 1800 MHz BogoMips: 3604.50 Cache: 512 kb single core As only Micheal and me reported this problem, it might be openSUSE-11-1 specific.=20 -Dieter --=20 Dieter Kl=C3=BCnter | Systemberatung http://www.dpunkt.de/buecher/2104.html sip: +49.180.1555.7770535 GPG Key ID:8EF7B6C6 53=C2=B008'09,95"N 10=C2=B008'02,42"E

1 0

Re: (ITS#6094) test054 doesn't replicate an entry
by hyc＠symas.com 16 Jun '09

16 Jun '09

dieter(a)dkluenter.de wrote: > Full_Name: Dieter Kluenter > Version: 2.4.16 > OS: Linux x86_64 > URL: http://dkluenter.de/download/dkluenter_test054.tgz > Submission from: (NULL) (87.154.44.82) > test054 doesn't replicate the entry dn: ou=Information Technolgy > Devision,ou=people,dc=example,dc=com > A tar archive containing the files > server1.flt, server2.flt, server1.log, server4.log > can be downloaded from the below URL To aid in reproducing this problem, please provide specific details on your platform: OS version, CPU architecture, and whether single core or multi-core. CPU model # may be helpful for comparison purposes. -- -- 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#6126) test054-syncreplication-parallel-load failed: producer and consumer databases differ
by hyc＠symas.com 16 Jun '09

16 Jun '09

michael(a)stroeder.com wrote: > I cannot reproduce it all the time. Can you add SYNC to your debug level and get the logs from one of these incidents? -- -- 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

OpenLDAP 2.4.11 and bdb: malloc: Cannot allocate memory
by Florian Genaudet 16 Jun '09

16 Jun '09

Hi all, I've got a problem with OpenLdap since I'm trying to insert 1,5 Million of entries into LDAP. OpenLDAP crash with "bdb: malloc: Cannot allocate memory" when approximately 950 000 entries are inserted. My computer got 2GB of RAM and here is my slapd.conf : # This is the main slapd configuration file. See slapd.conf(5) for more > # info on the configuration options. > > ####################################################################### > # Global Directives: > > # Features to permit > #allow bind_v2 > > # Schema and objectClass definitions > > include /etc/ldap/schema/core.schema > include /etc/ldap/schema/cosine.schema > include /etc/ldap/schema/nis.schema > include /etc/ldap/schema/inetorgperson.schema > #include /etc/schema/samba.schema > include /etc/ldap/schema/bvs.schema > > # Where the pid file is put. The init.d script > # will not stop the server if you change this. > pidfile /var/run/slapd/slapd.pid > > # List of arguments that were passed to the server > argsfile /var/run/slapd/slapd.args > > # Read slapd.conf(5) for possible values > loglevel none > > # Where the dynamically loaded modules are stored > modulepath /usr/lib/ldap > moduleload back_bdb > moduleload syncprov > > # logout idle clients after 10 seconds > idletimeout 10 > > # The maximum number of entries that is returned for a search operation > sizelimit unlimited > > #Specify the maximum number of pending requests for an anonymous session > conn_max_pending_auth 300 > > # The tool-threads parameter sets the actual amount of cpu's that is used > # for indexing. > tool-threads 2 > > > ####################################################################### > # Specific Backend Directives for hdb: > # Backend specific directives apply to this backend until another > # 'backend' directive occurs > backend bdb > > ####################################################################### > # Specific Backend Directives for 'other': > # Backend specific directives apply to this backend until another > # 'backend' directive occurs > #backend <other> > > ####################################################################### > # Specific Directives for database #1, of type hdb: > # Database specific directives apply to this databasse until another > # 'database' directive occurs > database bdb > > dbnosync > # updates are allowed to remain pending > cachesize 1500000 > > index sn,givenName pres,eq > index ENTPersonJointure eq > > > #overlay syncprov > > #syncprov-checkpoint 100 10 > #syncprov-sessionlog 100 > > > # The base of your directory in database #1 > suffix "dc=bvs,dc=fr" > > # rootdn directive for specifying a superuser on the database. This is > needed > # for syncrepl. > rootdn "cn=Manager,ou=ENTPerson,dc=bvs,dc=fr" > rootpw collaba > > # Where the database file are physically stored for database #1 > directory /var/lib/ldap > > # The dbconfig settings are used to generate a DB_CONFIG file the first > # time slapd starts. They do NOT override existing an existing DB_CONFIG > # file. You should therefore change these settings in DB_CONFIG directly > # or remove DB_CONFIG and restart slapd for changes to take effect. > > # For the Debian package we use 2MB as default but be sure to update this > # value if you have plenty of RAM > dbconfig set_cachesize 0 1024000 0 > dbconfig set_flags DB_TXN_NOSYNC > > > # Sven Hartge reported that he had to set this value incredibly high > # to get slapd running at all. See http://bugs.debian.org/303057 for more > # information. > > # Number of objects that can be locked at the same time. > dbconfig set_lk_max_objects 1500 > # Number of locks (both requested and granted) > dbconfig set_lk_max_locks 1500 > # Number of lockers > dbconfig set_lk_max_lockers 1500 > > # Indexing options for database #1 > index objectClass eq > > # Save the time that the entry gets modified, for database #1 > lastmod off > > # Checkpoint the BerkeleyDB database periodically in case of system > # failure and to speed slapd shutdown. > checkpoint 512000 30 > > # Where to store the replica logs for database #1 > # replogfile /var/lib/ldap/replog > > # Basic ACL (deprecated in favour of ACLs in > /etc/openldap/slapd.access.conf) > #access to attr=userPassword > # by self write > # by anonymous auth > # by dn="uid=root,ou=People,dc=example,dc=com" write > # by * none > > # ACL for "Enseignant" profile only (=> can modify all "userPassword" of > its own College) > access to > dn.regex="^cn=(.*),ou=entperson,ou=(.*),ou=(.*),dc=bvs,dc=fr$" > attrs=givenName > by set.regex="user/entPersonProfils & > [cn=Enseignant_$2,ou=entgroup,ou=$2,ou=$3,dc=bvs,dc=fr]" write > by * read > > # ACL for "Administrateur" profile only (=> can modify all data of its own > College) > access to dn.regex="^(.*),ou=(.*),ou=(.*),dc=bvs,dc=fr$" > by set.regex="user/entPersonProfils & > [cn=Administrateur_$2,ou=entgroup,ou=$2,ou=$3,dc=bvs,dc=fr]" write > by * read > > # ACL for "Eleve" profile only (=> can modify only its own "userPassword") > access to attrs=entPersonDateNaissance > by self write > by * read > > access to * > by * read > > ####################################################################### > # Specific Directives for database #2, of type 'other' (can be hdb too): > # Database specific directives apply to this databasse until another > # 'database' directive occurs > #database <other> > > # The base of your directory for database #2 > #suffix "dc=debian,dc=org" > > What am I doing wrong ? Regards.

2 1

Re: (ITS#6060) Admin guide doesn't describe converting from slapd.conf to cn=config
by hyc＠symas.com 15 Jun '09

15 Jun '09

Gavin Henry wrote: > > ----- hyc(a)symas.com wrote: > >> Gavin Henry wrote: >>> Thanks, I'll review and let you know. >>> >>> Gavin. >>> >> And while you're at it, please move the slapd config examples back to >> the end >> of the slapd config chapters where they originally came from. You can >> insert >> references like "for more detailed discussion of access controls go >> -there-" >> but the examples need to be in the config chapters. > > Do you mean like these: > > http://www.openldap.org/doc/admin23/slapdconf2.html#Configuration%20Example > http://www.openldap.org/doc/admin23/slapdconfig.html#Configuration%20File%2… Yes. > > What chapters have I stuck them in then? Will check and move them back. You moved them to Access Control. > Can't remember why I moved them at all. > > 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

Re: (ITS#6172) Crash with baseObject in back-sql
by masarati＠aero.polimi.it 15 Jun '09

15 Jun '09

openssl(a)mkarcher.dialup.fu-berlin.de wrote: > slapd gets terminated by libc with an "invalid free" error message when using > the baseObject configuration option (whether with or without file) at the time > of the first query. > > This is caused by freeing an entry using "free" that has been allocated using > "entry_dup". This does not match (any more?). Essentially what the code was > trying to to is to duplicate the sql_baseObject to bsi_e. The fix I suggest adds > a function "entry_dup_to" to slapd so that backends can do this operation > cleanly without having to create a temporary dynamic object there is no obvious > clean way to get rid of. I'd rather have a function that returns the entry struct to the pool without calling entry_clean(), to avoid as much as possible code duplication. In any case, good catch. Thanks, p.

1 0

Re: (ITS#6060) Admin guide doesn't describe converting from slapd.conf to cn=config
by ghenry＠OpenLDAP.org 15 Jun '09

15 Jun '09

----- hyc(a)symas.com wrote: > Gavin Henry wrote: > > Thanks, I'll review and let you know. > > > > Gavin. > > > And while you're at it, please move the slapd config examples back to > the end > of the slapd config chapters where they originally came from. You can > insert > references like "for more detailed discussion of access controls go > -there-" > but the examples need to be in the config chapters. Do you mean like these: http://www.openldap.org/doc/admin23/slapdconf2.html#Configuration%20Example http://www.openldap.org/doc/admin23/slapdconfig.html#Configuration%20File%2… What chapters have I stuck them in then? Will check and move them back. Can't remember why I moved them at all. Thanks. -- Kind Regards, Gavin Henry. OpenLDAP Engineering Team. E ghenry(a)OpenLDAP.org Community developed LDAP software. http://www.openldap.org/project/

1 0

(ITS#6172) Crash with baseObject in back-sql
by openssl＠mkarcher.dialup.fu-berlin.de 14 Jun '09

14 Jun '09

Full_Name: Michael Karcher Version: 2.4.11 OS: Debian Linux (squeeze) URL: ftp://ftp.openldap.org/incoming/Michael-Karcher-090614.diff.1 Submission from: (NULL) (87.123.80.3) slapd gets terminated by libc with an "invalid free" error message when using the baseObject configuration option (whether with or without file) at the time of the first query. This is caused by freeing an entry using "free" that has been allocated using "entry_dup". This does not match (any more?). Essentially what the code was trying to to is to duplicate the sql_baseObject to bsi_e. The fix I suggest adds a function "entry_dup_to" to slapd so that backends can do this operation cleanly without having to create a temporary dynamic object there is no obvious clean way to get rid of. I provide a patch to fix that problem. As it is mostly rearranging things, I don't think that patch is copyrightable.

1 0

Re: (ITS#6154) response/cleanup callback mismatch
by h.b.furuseth＠usit.uio.no 12 Jun '09

12 Jun '09

Aha, cleanup handers cannot assume response handler was called, for other reasons too. Fixed back-relay. -- Hallvard

1 0

(ITS#6171) Kill or fix K&R support
by h.b.furuseth＠usit.uio.no 12 Jun '09

12 Jun '09

Full_Name: Hallvard B Furuseth Version: 2.0.0 and later OS: URL: http://www.openldap.org/lists/openldap-devel/200706/msg00009.html Submission from: (NULL) (129.240.6.233) Submitted by: hallvard openldap-devel thread "Kill K&R C support?" from jun 2007, edited into a single quote/response stream: Hallvard B Furuseth wrote: >Kurt Zeilenga wrote: >>Hallvard B Furuseth wrote: >>> As far as I can tell, OpenLDAP has been unusable with K&R C since >>> openldap-2.0: lber.h in that release had prototypes unprotected >>> by LDAP_P() in struct sockbuf_io. They've been there ever since. >>> So LDAP_P() can [edit: probably] go. >> >> I note that the intent was to allow use of -lldap/-llber in K&R C >> programs, but to require ISO C to build OpenLDAP Software. > > Which I think made sense. But now, apparently nobody has complained > about the problem for 7 years. Time to quit worrying about K&R? > >> Seems the former is broken (lber.h issues). Still broken today (jun 2009). >>> Don't know which other not-strict-ISO support is still useful - >>> I note lber.h has used <string.h> since openldap-2.2.4, for example. >>> libldap/open.c has used <limits.h> since 2.0.0. >> >> The latter isn't a problem with regard to the above intent. >> >>> HEAD wraps that >>> in HAVE_LIMITS_H, but it does not protect INT_MAX the same way. >> >> Likewise.

1 0

Re: (ITS#6170) test039 seg faults
by michael＠stroeder.com 12 Jun '09

12 Jun '09

michael@nb2:/usr/src/michael/openldap/OPENLDAP_REL_ENG_2_4/openldap/tests> gdb -c core.22616 /usr/src/michael/openldap/OPENLDAP_REL_ENG_2_4/openldap/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 22784] [New Thread 22616] [New Thread 22926] [New Thread 22646] [New Thread 22965] [New Thread 22892] [New Thread 22950] [New Thread 22909] [New Thread 22875] [New Thread 22939] [New Thread 22816] [New Thread 22953] [New Thread 22848] [New Thread 22818] [New Thread 22631] [New Thread 22765] [New Thread 22937] 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 22937 0xffffe430 in __kernel_vsyscall () 17 Thread 22765 0xffffe430 in __kernel_vsyscall () 16 Thread 22631 0xffffe430 in __kernel_vsyscall () 15 Thread 22818 0xffffe430 in __kernel_vsyscall () 14 Thread 22848 0xffffe430 in __kernel_vsyscall () 13 Thread 22953 0xffffe430 in __kernel_vsyscall () 12 Thread 22816 0xffffe430 in __kernel_vsyscall () 11 Thread 22939 0xffffe430 in __kernel_vsyscall () 10 Thread 22875 0xffffe430 in __kernel_vsyscall () 9 Thread 22909 0xffffe430 in __kernel_vsyscall () 8 Thread 22950 0xffffe430 in __kernel_vsyscall () 7 Thread 22892 0xffffe430 in __kernel_vsyscall () 6 Thread 22965 0xffffe430 in __kernel_vsyscall () 5 Thread 22646 0xffffe430 in __kernel_vsyscall () 4 Thread 22926 0xffffe430 in __kernel_vsyscall () 3 Thread 22616 0xffffe430 in __kernel_vsyscall () 2 Thread 22784 0xffffe430 in __kernel_vsyscall () * 1 Thread 22800 0xffffe430 in __kernel_vsyscall () Thread 18 (Thread 22937): #0 0xffffe430 in __kernel_vsyscall () #1 0x40590ec6 in ?? () from /lib/libc.so.6 #2 0x405100ba in ?? () from /lib/libc.so.6 Backtrace stopped: previous frame identical to this frame (corrupt stack?) Thread 17 (Thread 22765): #0 0xffffe430 in __kernel_vsyscall () #1 0x40590e93 in ?? () from /lib/libc.so.6 #2 0x405100ae in ?? () from /lib/libc.so.6 Backtrace stopped: previous frame identical to this frame (corrupt stack?) Thread 16 (Thread 22631): #0 0xffffe430 in __kernel_vsyscall () #1 0x40584c56 in epoll_wait () from /lib/libc.so.6 #2 0x08073cf7 in slapd_daemon_task (ptr=0x0) at daemon.c:2325 #3 0x4024a1b5 in start_thread () from /lib/libpthread.so.0 #4 0x405843be in clone () from /lib/libc.so.6 Thread 15 (Thread 22818): #0 0xffffe430 in __kernel_vsyscall () #1 0x40590e93 in ?? () from /lib/libc.so.6 #2 0x405100ae in ?? () from /lib/libc.so.6 Backtrace stopped: previous frame identical to this frame (corrupt stack?) Thread 14 (Thread 22848): #0 0xffffe430 in __kernel_vsyscall () #1 0x40590e93 in ?? () from /lib/libc.so.6 #2 0x405100ae in ?? () from /lib/libc.so.6 Backtrace stopped: previous frame identical to this frame (corrupt stack?) Thread 13 (Thread 22953): #0 0xffffe430 in __kernel_vsyscall () #1 0x40590e93 in ?? () from /lib/libc.so.6 #2 0x405100ae in ?? () from /lib/libc.so.6 Backtrace stopped: previous frame identical to this frame (corrupt stack?) Thread 12 (Thread 22816): #0 0xffffe430 in __kernel_vsyscall () #1 0x4057a6a7 in poll () from /lib/libc.so.6 #2 0x40049f65 in ldap_int_select (ld=0x82a19d0, timeout=0x4235bb50) at os-ip.c:1056 #3 0x40031d1f in ldap_result (ld=0x82a19d0, msgid=25, all=1, timeout=0x4235bbd0, result=0x4235bbd8) at result.c:335 #4 0x4078b371 in ldap_back_op_result (lc=0x82a1678, op=0x8289c10, rs=0x4235c0c8, msgid=25, timeout=0, sendok=LDAP_BACK_RETRY_SRES) at bind.c:1704 #5 0x4078dd4f in ldap_back_modrdn (op=0x8289c10, rs=0x4235c0c8) at modrdn.c:95 #6 0x080e05fc in overlay_op_walk (op=0x8289c10, rs=0x4235c0c8, which=op_modrdn, oi=0x81d8be0, on=0x81d8ce0) at backover.c:669 #7 0x080e10f4 in over_op_func (op=0x8289c10, rs=0x4235c0c8, which=op_modrdn) at backover.c:721 #8 0x08092b4f in fe_op_modrdn (op=0x8289c10, rs=0x4235c0c8) at modrdn.c:314 #9 0x080e05fc in overlay_op_walk (op=0x8289c10, rs=0x4235c0c8, which=op_modrdn, oi=0x81ffac0, on=0x81ffbc0) at backover.c:669 #10 0x080e10f4 in over_op_func (op=0x8289c10, rs=0x4235c0c8, which=op_modrdn) at backover.c:721 #11 0x080936b7 in do_modrdn (op=0x8289c10, rs=0x4235c0c8) at modrdn.c:186 #12 0x080772ff in connection_operation (ctx=0x4235c1cc, arg_v=0x8289c10) at connection.c:1115 #13 0x08077c87 in connection_read_thread (ctx=0x4235c1cc, argv=0x15) at connection.c:1248 #14 0x4002f430 in ldap_int_thread_pool_wrapper (xpool=0x81c77e8) at tpool.c:698 #15 0x4024a1b5 in start_thread () from /lib/libpthread.so.0 #16 0x405843be in clone () from /lib/libc.so.6 Thread 11 (Thread 22939): #0 0xffffe430 in __kernel_vsyscall () #1 0x40590e93 in ?? () from /lib/libc.so.6 #2 0x405100ae in ?? () from /lib/libc.so.6 Backtrace stopped: previous frame identical to this frame (corrupt stack?) Thread 10 (Thread 22875): #0 0xffffe430 in __kernel_vsyscall () #1 0x4057a6a7 in poll () from /lib/libc.so.6 #2 0x40049f65 in ldap_int_select (ld=0x8289960, timeout=0x43362b50) at os-ip.c:1056 #3 0x40031d1f in ldap_result (ld=0x8289960, msgid=5, all=1, timeout=0x43362bd0, result=0x43362bd8) at result.c:335 #4 0x4078b371 in ldap_back_op_result (lc=0x8289920, op=0x82a0de0, rs=0x433630c8, msgid=5, timeout=0, sendok=LDAP_BACK_RETRY_SRES) at bind.c:1704 #5 0x4078dd4f in ldap_back_modrdn (op=0x82a0de0, rs=0x433630c8) at modrdn.c:95 #6 0x080e05fc in overlay_op_walk (op=0x82a0de0, rs=0x433630c8, which=op_modrdn, oi=0x81d8be0, on=0x81d8ce0) at backover.c:669 #7 0x080e10f4 in over_op_func (op=0x82a0de0, rs=0x433630c8, which=op_modrdn) at backover.c:721 #8 0x08092b4f in fe_op_modrdn (op=0x82a0de0, rs=0x433630c8) at modrdn.c:314 #9 0x080e05fc in overlay_op_walk (op=0x82a0de0, rs=0x433630c8, which=op_modrdn, oi=0x81ffac0, on=0x81ffbc0) at backover.c:669 #10 0x080e10f4 in over_op_func (op=0x82a0de0, rs=0x433630c8, which=op_modrdn) at backover.c:721 #11 0x080936b7 in do_modrdn (op=0x82a0de0, rs=0x433630c8) at modrdn.c:186 #12 0x080772ff in connection_operation (ctx=0x433631cc, arg_v=0x82a0de0) at connection.c:1115 #13 0x08077c87 in connection_read_thread (ctx=0x433631cc, argv=0xe) at connection.c:1248 #14 0x4002f430 in ldap_int_thread_pool_wrapper (xpool=0x81c77e8) at tpool.c:698 #15 0x4024a1b5 in start_thread () from /lib/libpthread.so.0 #16 0x405843be in clone () from /lib/libc.so.6 Thread 9 (Thread 22909): #0 0xffffe430 in __kernel_vsyscall () #1 0x4057a6a7 in poll () from /lib/libc.so.6 #2 0x40049f65 in ldap_int_select (ld=0x82b21d8, timeout=0x43d65a00) at os-ip.c:1056 #3 0x40031d1f in ldap_result (ld=0x82b21d8, msgid=1499, all=1, timeout=0x43d65a80, result=0x43d65a88) at result.c:335 #4 0x4078b371 in ldap_back_op_result (lc=0x82b1d28, op=0x82b2648, rs=0x43d670c8, msgid=1499, timeout=0, sendok=LDAP_BACK_RETRY_SRES) at bind.c:1704 #5 0x4078dadb in ldap_back_modify (op=0x82b2648, rs=0x43d670c8) at modify.c:111 #6 0x080e05fc in overlay_op_walk (op=0x82b2648, rs=0x43d670c8, which=op_modify, oi=0x81d8be0, on=0x81d8ce0) at backover.c:669 #7 0x080e10f4 in over_op_func (op=0x82b2648, rs=0x43d670c8, which=op_modify) at backover.c:721 #8 0x0809082d in fe_op_modify (op=0x82b2648, rs=0x43d670c8) at modify.c:301 #9 0x080e05fc in overlay_op_walk (op=0x82b2648, rs=0x43d670c8, which=op_modify, oi=0x81ffac0, on=0x81ffbc0) at backover.c:669 #10 0x080e10f4 in over_op_func (op=0x82b2648, rs=0x43d670c8, which=op_modify) at backover.c:721 #11 0x0809136f in do_modify (op=0x82b2648, rs=0x43d670c8) at modify.c:175 #12 0x080772ff in connection_operation (ctx=0x43d671cc, arg_v=0x82b2648) at connection.c:1115 #13 0x08077c87 in connection_read_thread (ctx=0x43d671cc, argv=0xf) at connection.c:1248 #14 0x4002f430 in ldap_int_thread_pool_wrapper (xpool=0x81c77e8) at tpool.c:698 #15 0x4024a1b5 in start_thread () from /lib/libpthread.so.0 #16 0x405843be in clone () from /lib/libc.so.6 Thread 8 (Thread 22950): #0 0xffffe430 in __kernel_vsyscall () #1 0x4057a6a7 in poll () from /lib/libc.so.6 #2 0x40049f65 in ldap_int_select (ld=0x82732c8, timeout=0x4516e9e0) at os-ip.c:1056 #3 0x40031d1f in ldap_result (ld=0x82732c8, msgid=36, all=1, timeout=0x4516ea60, result=0x4516ea68) at result.c:335 #4 0x4078b371 in ldap_back_op_result (lc=0x8273658, op=0x82e4298, rs=0x4516f0c8, msgid=36, timeout=0, sendok=LDAP_BACK_RETRY_SRES) at bind.c:1704 #5 0x4078d2b2 in ldap_back_add (op=0x82e4298, rs=0x4516f0c8) at add.c:104 #6 0x080e05fc in overlay_op_walk (op=0x82e4298, rs=0x4516f0c8, which=op_add, oi=0x81d8be0, on=0x81d8ce0) at backover.c:669 #7 0x080e10f4 in over_op_func (op=0x82e4298, rs=0x4516f0c8, which=op_add) at backover.c:721 #8 0x0807ea1f in fe_op_add (op=0x82e4298, rs=0x4516f0c8) at add.c:334 #9 0x080e05fc in overlay_op_walk (op=0x82e4298, rs=0x4516f0c8, which=op_add, oi=0x81ffac0, on=0x81ffbc0) at backover.c:669 #10 0x080e10f4 in over_op_func (op=0x82e4298, rs=0x4516f0c8, which=op_add) at backover.c:721 #11 0x0807f5bb in do_add (op=0x82e4298, rs=0x4516f0c8) at add.c:194 #12 0x080772ff in connection_operation (ctx=0x4516f1cc, arg_v=0x82e4298) at connection.c:1115 #13 0x08077c87 in connection_read_thread (ctx=0x4516f1cc, argv=0x2b) at connection.c:1248 #14 0x4002f430 in ldap_int_thread_pool_wrapper (xpool=0x81c77e8) at tpool.c:698 #15 0x4024a1b5 in start_thread () from /lib/libpthread.so.0 #16 0x405843be in clone () from /lib/libc.so.6 Thread 7 (Thread 22892): #0 0xffffe430 in __kernel_vsyscall () #1 0x4057a6a7 in poll () from /lib/libc.so.6 #2 0x40049f65 in ldap_int_select (ld=0x82e47f8, timeout=0x43863a00) at os-ip.c:1056 #3 0x40031d1f in ldap_result (ld=0x82e47f8, msgid=17, all=1, timeout=0x43863a80, result=0x43863a88) at result.c:335 #4 0x4078b371 in ldap_back_op_result (lc=0x82e4648, op=0x82ab258, rs=0x438650c8, msgid=17, timeout=0, sendok=LDAP_BACK_RETRY_SRES) at bind.c:1704 #5 0x4078dadb in ldap_back_modify (op=0x82ab258, rs=0x438650c8) at modify.c:111 #6 0x080e05fc in overlay_op_walk (op=0x82ab258, rs=0x438650c8, which=op_modify, oi=0x81d8be0, on=0x81d8ce0) at backover.c:669 #7 0x080e10f4 in over_op_func (op=0x82ab258, rs=0x438650c8, which=op_modify) at backover.c:721 #8 0x0809082d in fe_op_modify (op=0x82ab258, rs=0x438650c8) at modify.c:301 #9 0x080e05fc in overlay_op_walk (op=0x82ab258, rs=0x438650c8, which=op_modify, oi=0x81ffac0, on=0x81ffbc0) at backover.c:669 #10 0x080e10f4 in over_op_func (op=0x82ab258, rs=0x438650c8, which=op_modify) at backover.c:721 #11 0x0809136f in do_modify (op=0x82ab258, rs=0x438650c8) at modify.c:175 #12 0x080772ff in connection_operation (ctx=0x438651cc, arg_v=0x82ab258) at connection.c:1115 #13 0x08077c87 in connection_read_thread (ctx=0x438651cc, argv=0x19) at connection.c:1248 #14 0x4002f430 in ldap_int_thread_pool_wrapper (xpool=0x81c77e8) at tpool.c:698 #15 0x4024a1b5 in start_thread () from /lib/libpthread.so.0 #16 0x405843be in clone () from /lib/libc.so.6 Thread 6 (Thread 22965): #0 0xffffe430 in __kernel_vsyscall () #1 0x4057a6a7 in poll () from /lib/libc.so.6 #2 0x40049f65 in ldap_int_select (ld=0x83188d0, timeout=0x45b72b50) at os-ip.c:1056 #3 0x40031d1f in ldap_result (ld=0x83188d0, msgid=2, all=1, timeout=0x45b72bd0, result=0x45b72bd8) at result.c:335 #4 0x4078b371 in ldap_back_op_result (lc=0x82ab5d0, op=0x8315870, rs=0x45b730c8, msgid=2, timeout=0, sendok=LDAP_BACK_RETRY_SRES) at bind.c:1704 #5 0x4078dd4f in ldap_back_modrdn (op=0x8315870, rs=0x45b730c8) at modrdn.c:95 #6 0x080e05fc in overlay_op_walk (op=0x8315870, rs=0x45b730c8, which=op_modrdn, oi=0x81d8be0, on=0x81d8ce0) at backover.c:669 #7 0x080e10f4 in over_op_func (op=0x8315870, rs=0x45b730c8, which=op_modrdn) at backover.c:721 #8 0x08092b4f in fe_op_modrdn (op=0x8315870, rs=0x45b730c8) at modrdn.c:314 #9 0x080e05fc in overlay_op_walk (op=0x8315870, rs=0x45b730c8, which=op_modrdn, oi=0x81ffac0, on=0x81ffbc0) at backover.c:669 #10 0x080e10f4 in over_op_func (op=0x8315870, rs=0x45b730c8, which=op_modrdn) at backover.c:721 #11 0x080936b7 in do_modrdn (op=0x8315870, rs=0x45b730c8) at modrdn.c:186 #12 0x080772ff in connection_operation (ctx=0x45b731cc, arg_v=0x8315870) at connection.c:1115 #13 0x08077c87 in connection_read_thread (ctx=0x45b731cc, argv=0x25) at connection.c:1248 #14 0x4002f430 in ldap_int_thread_pool_wrapper (xpool=0x81c77e8) at tpool.c:698 #15 0x4024a1b5 in start_thread () from /lib/libpthread.so.0 #16 0x405843be in clone () from /lib/libc.so.6 Thread 5 (Thread 22646): #0 0xffffe430 in __kernel_vsyscall () #1 0x4057a6a7 in poll () from /lib/libc.so.6 #2 0x40049f65 in ldap_int_select (ld=0x82b7d80, timeout=0x41054bc0) at os-ip.c:1056 #3 0x40031d1f in ldap_result (ld=0x82b7d80, msgid=6, all=1, timeout=0x41054c40, result=0x41054c48) at result.c:335 #4 0x4078b371 in ldap_back_op_result (lc=0x82b7d40, op=0x825ea70, rs=0x410550c8, msgid=6, timeout=0, sendok=LDAP_BACK_RETRY_SRES) at bind.c:1704 #5 0x4078d75a in ldap_back_delete (op=0x825ea70, rs=0x410550c8) at delete.c:62 #6 0x080e05fc in overlay_op_walk (op=0x825ea70, rs=0x410550c8, which=op_delete, oi=0x81d8be0, on=0x81d8ce0) at backover.c:669 #7 0x080e10f4 in over_op_func (op=0x825ea70, rs=0x410550c8, which=op_delete) at backover.c:721 #8 0x080917cb in fe_op_delete (op=0x825ea70, rs=0x410550c8) at delete.c:174 #9 0x080e05fc in overlay_op_walk (op=0x825ea70, rs=0x410550c8, which=op_delete, oi=0x81ffac0, on=0x81ffbc0) at backover.c:669 #10 0x080e10f4 in over_op_func (op=0x825ea70, rs=0x410550c8, which=op_delete) at backover.c:721 #11 0x08091d86 in do_delete (op=0x825ea70, rs=0x410550c8) at delete.c:95 #12 0x080772ff in connection_operation (ctx=0x410551cc, arg_v=0x825ea70) at connection.c:1115 #13 0x08077c87 in connection_read_thread (ctx=0x410551cc, argv=0x12) at connection.c:1248 #14 0x4002f430 in ldap_int_thread_pool_wrapper (xpool=0x81c77e8) at tpool.c:698 #15 0x4024a1b5 in start_thread () from /lib/libpthread.so.0 #16 0x405843be in clone () from /lib/libc.so.6 Thread 4 (Thread 22926): #0 0xffffe430 in __kernel_vsyscall () #1 0x4057a6a7 in poll () from /lib/libc.so.6 #2 0x40049f65 in ldap_int_select (ld=0x82f0db8, timeout=0x442689e0) at os-ip.c:1056 #3 0x40031d1f in ldap_result (ld=0x82f0db8, msgid=2, all=1, timeout=0x44268a60, result=0x44268a68) at result.c:335 #4 0x4078b371 in ldap_back_op_result (lc=0x82f0c30, op=0x82b5cb8, rs=0x442690c8, msgid=2, timeout=0, sendok=LDAP_BACK_RETRY_SRES) at bind.c:1704 #5 0x4078d2b2 in ldap_back_add (op=0x82b5cb8, rs=0x442690c8) at add.c:104 #6 0x080e05fc in overlay_op_walk (op=0x82b5cb8, rs=0x442690c8, which=op_add, oi=0x81d8be0, on=0x81d8ce0) at backover.c:669 #7 0x080e10f4 in over_op_func (op=0x82b5cb8, rs=0x442690c8, which=op_add) at backover.c:721 #8 0x0807ea1f in fe_op_add (op=0x82b5cb8, rs=0x442690c8) at add.c:334 #9 0x080e05fc in overlay_op_walk (op=0x82b5cb8, rs=0x442690c8, which=op_add, oi=0x81ffac0, on=0x81ffbc0) at backover.c:669 #10 0x080e10f4 in over_op_func (op=0x82b5cb8, rs=0x442690c8, which=op_add) at backover.c:721 #11 0x0807f5bb in do_add (op=0x82b5cb8, rs=0x442690c8) at add.c:194 #12 0x080772ff in connection_operation (ctx=0x442691cc, arg_v=0x82b5cb8) at connection.c:1115 #13 0x08077c87 in connection_read_thread (ctx=0x442691cc, argv=0x1e) at connection.c:1248 #14 0x4002f430 in ldap_int_thread_pool_wrapper (xpool=0x81c77e8) at tpool.c:698 #15 0x4024a1b5 in start_thread () from /lib/libpthread.so.0 #16 0x405843be in clone () from /lib/libc.so.6 at bind.c:1704 #5 0x4078d75a in ldap_back_delete (op=0x825ea70, rs=0x410550c8) at delete.c:62 #6 0x080e05fc in overlay_op_walk (op=0x825ea70, rs=0x410550c8, which=op_delete, oi=0x81d8be0, on=0x81d8ce0) at backover.c:669 #7 0x080e10f4 in over_op_func (op=0x825ea70, rs=0x410550c8, which=op_delete) at backover.c:721 #8 0x080917cb in fe_op_delete (op=0x825ea70, rs=0x410550c8) at delete.c:174 #9 0x080e05fc in overlay_op_walk (op=0x825ea70, rs=0x410550c8, which=op_delete, oi=0x81ffac0, on=0x81ffbc0) at backover.c:669 #10 0x080e10f4 in over_op_func (op=0x825ea70, rs=0x410550c8, which=op_delete) at backover.c:721 #11 0x08091d86 in do_delete (op=0x825ea70, rs=0x410550c8) at delete.c:95 #12 0x080772ff in connection_operation (ctx=0x410551cc, arg_v=0x825ea70) at connection.c:1115 #13 0x08077c87 in connection_read_thread (ctx=0x410551cc, argv=0x12) at connection.c:1248 #14 0x4002f430 in ldap_int_thread_pool_wrapper (xpool=0x81c77e8) at tpool.c:698 #15 0x4024a1b5 in start_thread () from /lib/libpthread.so.0 #16 0x405843be in clone () from /lib/libc.so.6 Thread 4 (Thread 22926): #0 0xffffe430 in __kernel_vsyscall () #1 0x4057a6a7 in poll () from /lib/libc.so.6 #2 0x40049f65 in ldap_int_select (ld=0x82f0db8, timeout=0x442689e0) at os-ip.c:1056 #3 0x40031d1f in ldap_result (ld=0x82f0db8, msgid=2, all=1, timeout=0x44268a60, result=0x44268a68) at result.c:335 #4 0x4078b371 in ldap_back_op_result (lc=0x82f0c30, op=0x82b5cb8, rs=0x442690c8, msgid=2, timeout=0, sendok=LDAP_BACK_RETRY_SRES) at bind.c:1704 #5 0x4078d2b2 in ldap_back_add (op=0x82b5cb8, rs=0x442690c8) at add.c:104 #6 0x080e05fc in overlay_op_walk (op=0x82b5cb8, rs=0x442690c8, which=op_add, oi=0x81d8be0, on=0x81d8ce0) at backover.c:669 #7 0x080e10f4 in over_op_func (op=0x82b5cb8, rs=0x442690c8, which=op_add) at backover.c:721 #8 0x0807ea1f in fe_op_add (op=0x82b5cb8, rs=0x442690c8) at add.c:334 #9 0x080e05fc in overlay_op_walk (op=0x82b5cb8, rs=0x442690c8, which=op_add, oi=0x81ffac0, on=0x81ffbc0) at backover.c:669 #10 0x080e10f4 in over_op_func (op=0x82b5cb8, rs=0x442690c8, which=op_add) at backover.c:721 #11 0x0807f5bb in do_add (op=0x82b5cb8, rs=0x442690c8) at add.c:194 #12 0x080772ff in connection_operation (ctx=0x442691cc, arg_v=0x82b5cb8) at connection.c:1115 #13 0x08077c87 in connection_read_thread (ctx=0x442691cc, argv=0x1e) at connection.c:1248 #14 0x4002f430 in ldap_int_thread_pool_wrapper (xpool=0x81c77e8) at tpool.c:698 #15 0x4024a1b5 in start_thread () from /lib/libpthread.so.0 #16 0x405843be in clone () from /lib/libc.so.6 ---Type <return> to continue, or q <return> to quit--- Thread 3 (Thread 22616): #0 0xffffe430 in __kernel_vsyscall () #1 0x4024a747 in pthread_join () from /lib/libpthread.so.0 #2 0x40030204 in ldap_pvt_thread_join (thread=1086671760, thread_return=0x0) at thr_posix.c:197 #3 0x080710f3 in slapd_daemon () at daemon.c:2700 #4 0x0805e205 in main (argc=8, argv=0xbf859b34) at main.c:950 Thread 2 (Thread 22784): #0 0xffffe430 in __kernel_vsyscall () #1 0x40590e93 in ?? () from /lib/libc.so.6 #2 0x405100ae in ?? () from /lib/libc.so.6 Backtrace stopped: previous frame identical to this frame (corrupt stack?) Thread 1 (Thread 22800): #0 0xffffe430 in __kernel_vsyscall () #1 0x404dd990 in raise () from /lib/libc.so.6 #2 0x404df2c8 in abort () from /lib/libc.so.6 #3 0x404d678e in __assert_fail () from /lib/libc.so.6 #4 0x4078a0eb in ldap_back_conn_delete (li=0x8202d90, lc=0x82a17e8) at bind.c:157 #5 0x4078af81 in ldap_back_freeconn (li=0x8202d90, lc=0x82a17e8, dolock=0) at bind.c:467 #6 0x4078b059 in ldap_back_release_conn_lock (li=0x8202d90, lcp=0x41f5ace8, dolock=1) at bind.c:1147 #7 0x4078cc2d in ldap_back_bind (op=0x8289088, rs=0x41f5b0c8) at bind.c:355 #8 0x080e05fc in overlay_op_walk (op=0x8289088, rs=0x41f5b0c8, which=op_bind, oi=0x81d8be0, on=0x81d8ce0) at backover.c:669 #9 0x080e10f4 in over_op_func (op=0x8289088, rs=0x41f5b0c8, which=op_bind) at backover.c:721 #10 0x08095b5c in fe_op_bind (op=0x8289088, rs=0x41f5b0c8) at bind.c:383 #11 0x080e05fc in overlay_op_walk (op=0x8289088, rs=0x41f5b0c8, which=op_bind, oi=0x81ffac0, on=0x81ffbc0) at backover.c:669 #12 0x080e10f4 in over_op_func (op=0x8289088, rs=0x41f5b0c8, which=op_bind) at backover.c:721 #13 0x08096692 in do_bind (op=0x8289088, rs=0x41f5b0c8) at bind.c:205 #14 0x080772ff in connection_operation (ctx=0x41f5b1cc, arg_v=0x8289088) at connection.c:1115 #15 0x08077c87 in connection_read_thread (ctx=0x41f5b1cc, argv=0x2c) at connection.c:1248 #16 0x4002f430 in ldap_int_thread_pool_wrapper (xpool=0x81c77e8) at tpool.c:698 #17 0x4024a1b5 in start_thread () from /lib/libpthread.so.0 #18 0x405843be in clone () from /lib/libc.so.6

1 0

Re: (ITS#6170) test039 seg faults
by michael＠stroeder.com 12 Jun '09

12 Jun '09

tests/testrun/ available under: http://www.stroeder.com/temp/openldap/its6170_test039-testrun.tar.gz

1 0

(ITS#6170) test039 seg faults
by michael＠stroeder.com 12 Jun '09

12 Jun '09

Full_Name: Michael Ströder Version: RE24 synced recently OS: openSUSE Linux 11.1 URL: Submission from: (NULL) (84.163.103.142) I cannot tell whether that's a dup of ITS#5733. ----------------------------- Console 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=22677 - Search(500): base="o=Example,c=US" scope=sub filter="(cn=Barbara Jensen)" attrs=cn (more...). PID=22679 - Read(1000): entry="cn=Barbara Jensen,ou=Information Technology Division,ou=People,o=Example,c=US". PID=22685 - Modrdn(50): entry="cn=Dorothy Stevens,ou=Alumni Association,ou=People,o=Example,c=US". PID=22690 - Modify(50): entry="cn=Barbara Jensen,ou=Information Technology Division,ou=People,o=Example,c=US". PID=22695 - Add/Delete(50): entry="cn=James A Jones 3,ou=Alumni Association,ou=People,o=Example,c=US". PID=22705 - Bind(1000): dn="cn=Barbara Jensen,ou=Information Technology Division,ou=People,o=Example,c=US". slapd-bind PID=22705: ldap_sasl_bind_s: Invalid credentials (49) PID=22715 - Search(500): base="ou=people,o=Example,c=US" scope=sub filter="(cn=Bjorn Jensen)" attrs=cn (more...). PID=22737 - Modrdn(50): entry="cn=John Doe,ou=Information Technology Division,ou=People,o=Example,c=US". PID=22724 - Read(1000): entry="cn=ITD Staff,ou=Groups,o=Example,c=US". PID=22746 - Modify(50): entry="cn=Bjorn Jensen,ou=Information Technology Division,ou=People,o=Example,c=US". PID=22758 - Add/Delete(50): entry="cn=James A Jones 5,o=Example,c=US". PID=22772 - Bind(1000): dn="cn=Bjorn Jensen,ou=Information Technology Division,ou=People,o=Example,c=US". PID=22786 - Search(500): base="ou=people,o=Example,c=US" scope=sub filter="(cn=James A Jones 1)" attrs=cn (more...). PID=22801 - Read(1000): entry="ou=Groups, o=Example,c=US". PID=22817 - Modrdn(50): entry="cn=Ursula Hampster,ou=Alumni Association,ou=People,o=Example,c=US". PID=22833 - Modify(50): entry="cn=James A Jones 1,ou=Alumni Association,ou=People,o=Example,c=US". PID=22850 - Add/Delete(50): entry="cn=James A Jones 2,ou=Alumni Association,ou=People,o=Example,c=US". PID=22882 - Search(500): base="o=Example,c=US" scope=sub filter="(cn=Bjorn Jensen)" attrs=cn (more...). PID=22863 - Bind(1000): base="ou=People,o=Example,c=US", filter="(userPassword=*)" attr="userPassword". PID=22898 - Read(1000): entry="ou=Alumni Association, ou=People, o=Example,c=US". PID=22863 - Bind base="ou=People,o=Example,c=US" filter="(userPassword=*)" got 3 values. slapd-bind PID=22863: ldap_sasl_bind_s: Invalid credentials (49) slapd-search PID=22677: ldap_search_ext_s: Can't contact LDAP server (-1) base="o=Example,c=US" filter="(cn=Barbara Jensen)" PID=22677 - Search done (-1). slapd-read PID=22679: ldap_search_ext_s(cn=Barbara Jensen,ou=Information Technology Division,ou=People,o=Example,c=US): Can't contact LDAP server (-1) PID=22679 - Read done (-1). slapd-modrdn PID=22685: ldap_rename_s: Can't contact LDAP server (-1) PID=22685 - Modrdn done (-1). slapd-modify PID=22690: ldap_modify_ext_s: Can't contact LDAP server (-1) PID=22690 - Modify done (-1). slapd-addel PID=22695: ldap_delete_ext_s: Can't contact LDAP server (-1) PID=22695 - Add/Delete done (-1). slapd-bind PID=22705: ldap_sasl_bind_s: Can't contact LDAP server (-1) PID=22705 - Bind done (-1). slapd-modrdn PID=22737: ldap_rename_s: Can't contact LDAP server (-1) PID=22737 - Modrdn done (-1). slapd-search PID=22715: ldap_search_ext_s: Can't contact LDAP server (-1) base="ou=people,o=Example,c=US" filter="(cn=Bjorn Jensen)" PID=22715 - Search done (-1). slapd-read PID=22724: ldap_search_ext_s(cn=ITD Staff,ou=Groups,o=Example,c=US): Can't contact LDAP server (-1) PID=22724 - Read done (-1). slapd-modify PID=22833: ldap_modify_ext_s: Can't contact LDAP server (-1) PID=22833 - Modify done (-1). slapd-modify PID=22746: ldap_modify_ext_s: Can't contact LDAP server (-1) PID=22746 - Modify done (-1). slapd-addel PID=22758: ldap_add_ext_s: Can't contact LDAP server (-1) PID=22758 - Add/Delete done (-1). slapd-bind PID=22772: ldap_sasl_bind_s: Can't contact LDAP server (-1) PID=22772 - Bind done (-1). slapd-search PID=22786: ldap_search_ext_s: Can't contact LDAP server (-1) base="ou=people,o=Example,c=US" filter="(cn=James A Jones 1 )" PID=22786 - Search done (-1). slapd-modrdn PID=22817: ldap_rename_s: Can't contact LDAP server (-1) PID=22817 - Modrdn done (-1). slapd-read PID=22801: ldap_search_ext_s(ou=Groups, o=Example,c=US): Can't contact LDAP server (-1) PID=22801 - Read done (-1). slapd-addel PID=22850: ldap_add_ext_s: Can't contact LDAP server (-1) PID=22850 - Add/Delete done (-1). slapd-bind PID=22863: ldap_sasl_bind_s: Can't contact LDAP server (-1) PID=22863 - Bind done 1 in 3.719714 seconds. slapd-search PID=22882: ldap_search_ext_s: Can't contact LDAP server (-1) base="o=Example,c=US" filter="(cn=Bjorn Jensen)" PID=22882 - Search done (-1). slapd-read PID=22898: ldap_search_ext_s(ou=Alumni Association, ou=People, o=Example,c=US): Can't contact LDAP server (-1) PID=22898 - Read done (-1). PID=22986 - Modrdn(50): entry="cn=James A Jones 2,ou=Information Technology Division,ou=People,o=Example,c=US". slapd-modrdn PID=22986: ldap_sasl_bind_s: Can't contact LDAP server (-1) PID=22990 - Modify(50): entry="cn=ITD Staff,ou=Groups,o=Example,c=US". PID=22992 - Add/Delete(50): entry="cn=James A Jones 4,ou=People,o=Example,c=US". slapd-modify PID=22990: ldap_sasl_bind_s: Can't contact LDAP server (-1) slapd-addel PID=22992: ldap_sasl_bind_s: Can't contact LDAP server (-1) PID=22999 - Bind(1000): dn="cn=Foo,ou=Meta,o=Example,c=US". slapd-bind PID=22999: ldap_sasl_bind_s: Can't contact LDAP server (-1) PID=22999 - Bind done (-1). PID=23005 - Search(500): base="o=Example,c=US" scope=sub filter="(cn=Alumni Assoc Staff)" attrs=cn (more...). slapd-search PID=23005: ldap_sasl_bind_s: Can't contact LDAP server (-1) bindDN="cn=Manager,o=Example,c=US" PID=23013 - Read(1000): entry="cn=James A Jones 1, ou=Alumni Association, ou=People, o=Example,c=US". slapd-read PID=23013: ldap_sasl_bind_s: Can't contact LDAP server (-1) PID=23022 - Bind(1000): dn="". slapd-bind PID=23022: ldap_sasl_bind_s: Can't contact LDAP server (-1) PID=23022 - Bind done (-1). PID=23032 - Search(500): base="o=Example,c=US" scope=sub filter="(cn=James*)" attrs=cn (more...). slapd-search PID=23032: ldap_sasl_bind_s: Can't contact LDAP server (-1) bindDN="cn=Manager,o=Example,c=US" PID=23041 - Read(1000): entry="ou=Meta,o=Example,c=US". PID=23053 - Bind(1000): dn="cn=Barbara Jensen,ou=Information Technology Division,ou=People,o=Example,c=US". slapd-read PID=23041: ldap_sasl_bind_s: Can't contact LDAP server (-1) stopping: child exited with status 1 ./scripts/test039-glue-ldap-concurrency: line 188: 22616 Aborted (core dumped) $SLAPD -f $CONF3 -h $URI3 -d $LVL $TIMI NG > $LOG3 2>&1 slapd-tester failed (1)! ./scripts/test039-glue-ldap-concurrency: line 193: kill: (22616) - 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 slapd-bind PID=23053: ldap_sasl_bind_s: Can't contact LDAP server (-1) PID=23066 - Search(500): base="cn=Monitor" scope=sub filter="(objectClass=*)" attrs=cn (more...). PID=23053 - Bind done (-1). slapd-search PID=23066: ldap_sasl_bind_s: Can't contact LDAP server (-1) bindDN="cn=Manager,o=Example,c=US" PID=23091 - Bind(1000): dn="cn=Bjorn Jensen,ou=Information Technology Division,ou=People,o=Example,c=US". PID=23077 - Read(1000): entry="cn=Somewhere,ou=Meta,o=Example,c=US". slapd-bind PID=23091: ldap_sasl_bind_s: Can't contact LDAP server (-1) PID=23091 - Bind done (-1). slapd-read PID=23077: ldap_sasl_bind_s: Can't contact LDAP server (-1) PID=23106 - Search(500): base="cn=Monitor" scope=sub filter="(objectClass=*)" attrs=cn (more...). michael@nb2:/usr/src/michael/openldap/OPENLDAP_REL_ENG_2_4/openldap> slapd-search PID=23106: ldap_sasl_bind_s: Can't contact LDAP serv er (-1) bindDN="cn=Manager,o=Example,c=US" PID=23119 - Read(1000): entry="cn=Backend 1,cn=Backends,cn=Monitor". slapd-read PID=23119: ldap_sasl_bind_s: Can't contact LDAP server (-1) slapd-bind PID=23135: ldap_sasl_bind_s: Can't contact LDAP server (-1) PID=23152 - Search(500): base="cn=Monitor" scope=sub filter="(objectClass=*)" attrs=cn (more...). slapd-search PID=23152: ldap_sasl_bind_s: Can't contact LDAP server (-1) bindDN="cn=Manager,o=Example,c=US" PID=23181 - Bind(1000): dn="cn=Foo,ou=Meta,o=Example,c=US". slapd-bind PID=23181: ldap_sasl_bind_s: Can't contact LDAP server (-1) PID=23181 - Bind done (-1). PID=23165 - Read(1000): entry="cn=Entries,cn=Statistics,cn=Monitor". slapd-read PID=23165: ldap_sasl_bind_s: Can't contact LDAP server (-1) PID=23194 - Search(500): base="cn=Monitor" scope=sub filter="(objectClass=*)" attrs=cn (more...). slapd-search PID=23194: ldap_sasl_bind_s: Can't contact LDAP server (-1) bindDN="cn=Manager,o=Example,c=US"

1 0

(ITS#6169) dds overlay bug(s) when expiring entries
by h.b.furuseth＠usit.uio.no 10 Jun '09

10 Jun '09

Full_Name: Hallvard B Furuseth Version: HEAD, RE24 OS: Linux URL: Submission from: (NULL) (129.240.6.233) Submitted by: hallvard Thinko in dds_expire(): Traversing a list chained on (struct dds_expire_t).de_next, it keeps dds_expire_t **dep == &(previous element).de_next. Before freeing (de = *dep), it points dep into de. Fixing. Suspicious code in same function: The 'default:' branch says "deferring" (deferring what? deletion?) and does not increment ndeletes, yet 'dds_expire_t *de' is deleted in that case as well. Is that intentional? I don't know dds. If it's not, we could just move the free() into 'case LDAP_SUCCESS:' and remove the 'de = NULL;' in the LDAP_NOT_ALLOWED_ON_NONLEAF case.

1 0

(ITS#6168) Account locked without associated ppolicy
by coudot＠linagora.com 10 Jun '09

10 Jun '09

Full_Name: Clement OUDOT Version: 2.4.16 OS: Linux 2.6.18 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (83.145.72.122) Hello, I have a ppolicy overlay without default ppolicy: --- overlay ppolicy ppolicy_use_lockout ppolicy_hash_cleartext --- So only users with pwdPolicySubEntry should be submitted to password policy. But if I add "pwdAccountLockedTime: 000001010000Z" to an entry without pwdPolicySubEntry, this entry is locked.

1 0

OpenLDAP dynamic configuration prefomance issue
by Dmitry Korotkov 09 Jun '09

09 Jun '09

Dear OpenLDAP team, I made some OpenLDAP stress tests on our use cases and realized that time of registering new objectClass using OpenLDAP dynamic configuration grows linearly. It looks like slapd completely rewrites contents of cn=config folder on any configuration change. This issue makes OpenLDAP schema to be a bottleneck in our large scalable application. Do you plan to store OpenLDAP configuration in bdb or hdb database? Or another solution of this issue is planned? WBR, Dmitry V. Korotkov

2 2

(ITS#6167) back-ldap: TLS: uri list broken
by christian.fischer＠fischundfischer.com 09 Jun '09

09 Jun '09

Full_Name: Christian Fischer Version: 2.4.16 OS: gentoo amd64 URL: Submission from: (NULL) (213.221.82.34) back-ldap hangs on ldap_back_bind() while starting TLS if the first mirror in uri list is down ldap_pvt_thread_mutex_lock() in back-ldap/bind.c:1584 never returns and slapd hangs reproducible: always steps to reproduce: - configure a uri list with two mirrors, the first one offline, start TLS database ldap suffix "dc=foo,dc=bar" uri "ldap://mirror01.foo.bar ldap://mirror02.foo.bar" tls start tls_reqcert=never

1 0

(ITS#6166) Overlay/backend restructuring
by h.b.furuseth＠usit.uio.no 08 Jun '09

08 Jun '09

Full_Name: Hallvard B Furuseth Version: RE25/RE30 OS: URL: Submission from: (NULL) (129.240.6.233) Submitted by: hallvard Some wishes/loose thoughts about overlay/backend code: * Remove backends internally, making them like overlays? (RE30) * Reduce copying of overlay data -op->o_bd->bd_info (RE25?) * Lose slap_overinst, move its members into BackendInfo. <hbf> Could we reduce complexity if there internally were no (programmable) backends, only overlays? Backends would be thinly disguised overlays. Maybe over a single fixed "core overlay" which intercepts all calls, or the opposite - a fixed empty backend. <hbf> .what do overlays cost compared to backends? Must reduce copying, but that seems already to be the plan. And slapd must repair some data structures which overlays are not required to clean up - must that stay? Am I talking sense at all? <hyc> eh, not sure what you're really talking about. turn all backends into overlays, to keep the API completely uniform? <hbf> yes. and return values the same way - SLAP_CB_CONTINUE when they don't know what to do, for example. <hbf> there seems to be code snippets around doing similar things for backends and overlays, and they mostly share the same data structure. so i wondered if the backend stuff could simply go away. <hyc> so we'd still need special cases in the frontend to handle SLAP_CB_CONTINUE falling out at the end <hyc> ideally, sure. <hyc> that seems like more of a 3.0 move than a 2.5 <hbf> yes, i suppose so <hbf> and it depends on overlays being as fast as backends <hyc> fast at what? <hyc> there's no measurable overhead for overlays on top of backends <hbf> handling a request. slapd does all this copying of overlay structures that I haven't even tried to figure out, I assume that costs time compared to a backend. <hyc> well, a lot of that copying can go away if we just rationalize the on_info stuff <hyc> I already mentioned that on -devel a while back <hyc> op->o_bd->bd_info <hyc> if we referenced those pointers from op instead of op->o_bd we'd need no copying at all <hyc> but i think that would require changes to a lot of existing backend code. <hyc> the copying approach was taken to allow overlays to be slotted in without modifying any backend code <hbf> oh well, we've more pressing problems in that case <hyc> actually come to think of it most backends don't care as it is. at this point it's the overlays and bconfig that would need to be changed <hyc> I guess we should have made that change sooner rather than later, as now the number of overlays is quite large :P <hyc> hindsight, oh well. <hyc> I wouldn't be opposed to attempting that change for 2.5. sooner is obviously better now. <hbf> related loose thought: overlays could lose all those (slap_overinst *)op->o_bd->bd_info casts if the slap_overinst members were inserted in BackendInfo and slap_overinst became an obsolete wrapper about just BackendInfo. Costs ~24 bytes/backend. <hyc> ok <hyc> that sounds smart

1 0

Re: (ITS#6161) test058-syncrepl-asymmetric failed (exit 6)
by michael＠stroeder.com 08 Jun '09

08 Jun '09

rein(a)OpenLDAP.org wrote: > michael(a)stroeder.com wrote: > >> Found 6 errors >>>>>>> ./scripts/test058-syncrepl-asymmetric failed (exit 6) > > Do you have the entire output from the test script? You mean the console output? Unfortunately not. As said I've generated a tar.gz of the whole testrun/ directory though: http://www.stroeder.com/temp/openldap/its6161-testrun.tar.gz > [..] without it I'm tempted to assume it > failed due to some timing glitch within the test script itself.. Hmm, how to find out? Ciao, Michael.

1 0

(ITS#6165) Support offline modify (slapmodify) for cn=config
by quanah＠OpenLDAP.org 08 Jun '09

08 Jun '09

Full_Name: Quanah Gibson-Mount Version: 2.4.16 OS: NA URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.111.29.239) The slapmodify function already exists, but we've never built a tool around it. It would be useful to be able to have a utility that validates commands that users can use to modify cn=config while slapd is offline, rather than resorting to text editors that don't do validation of the changes being made.

1 0

Re: (ITS#6161) test058-syncrepl-asymmetric failed (exit 6)
by rein＠OpenLDAP.org 08 Jun '09

08 Jun '09

michael(a)stroeder.com wrote: > Found 6 errors >>>>>> ./scripts/test058-syncrepl-asymmetric failed (exit 6) Do you have the entire output from the test script? It is required to tell what actually went wrong, and without it I'm tempted to assume it failed due to some timing glitch within the test script itself.. Rein

1 0

(ITS#6164) send_ldap_ber() spins holding c_write1_mutex
by h.b.furuseth＠usit.uio.no 08 Jun '09

08 Jun '09

Full_Name: Hallvard B Furuseth Version: HEAD OS: URL: Submission from: (NULL) (129.240.6.233) Submitted by: hallvard send_ldap_ber() has a suspicious-looking waitloop doing this: if ( ldap_pvt_thread_mutex_trylock( &conn->c_mutex )) { ldap_pvt_thread_mutex_unlock( &conn->c_write1_mutex ); ldap_pvt_thread_mutex_lock( &conn->c_write1_mutex ); Unlock does not mean a thread waiting for c_write1_mutex will acquire it immediately. Such a thread may have to wait until it is scheduled, at which time the looping thread has locked the mutex again. On the Linux box on my desk, a pure unlock-lock loop goes through 50000-100000 iterations before another thread waiting for the lock acquires it. OTOH, on a heavily used box it takes ~50 iterations. A sched_yield() between the unlock and lock reduces #iterations to 1. No idea if that is the right solution, nor how serious the problem is. The lock/unlock statements themselves are from result.c rev 1.323, but then with some more locking between them which disappeared in later revisions. My lock-unlock test program: #include <pthread.h> #include <sched.h> #include <stdio.h> #include <stdlib.h> #include <sys/select.h> static pthread_mutex_t m = PTHREAD_MUTEX_INITIALIZER; static unsigned count; static void *waiter(void *arg) { pthread_mutex_lock(&m); printf("Locked after %u iterations.\n", count); exit(0); } int main() { pthread_t t; pthread_mutex_lock(&m); pthread_create(&t, NULL, waiter, NULL); select(0, NULL, NULL, NULL, &(struct timeval){0, 100000}); for (count = 1 ;; ++count) { pthread_mutex_unlock(&m); pthread_mutex_lock(&m); } }

1 0

(ITS#6163) back-sql DoS when searching for empty attr
by karavelov＠spnet.net 08 Jun '09

08 Jun '09

Full_Name: Luben Karavelov Version: 2.4.11-15 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (78.83.96.32) We use ldap for some user accounts authentication here and we have found that queries of this kind : ldapsearch -b "dc=users,dc=example,dc=com" "(&(objectClass=posixAccount)(uid=))" kill slapd. It exits on assert( 0 ) at line 1366 of back-sql/search.c It is even nastier because it could be remotely triggered with ssh -l "" server-with-ldap-accounts-in-nss.example.com or through ftp using the same technique.

1 0

Re: (ITS#6151) Update cosine.schema to RFC 4524
by michael＠stroeder.com 08 Jun '09

08 Jun '09

Kurt Zeilenga wrote: > > On Jun 1, 2009, at 4:30 AM, michael(a)stroeder.com wrote: >> Updated schema file cosine-update.schema attached. > > I note that differs are generally preferred, even where the file is > mostly changed. This helps ensure changes that others might make to the > file you started with are not lost. I thought about sending a diff but the file in this form is more readable for easy review. Could someone please look at it whether that's ok? Another approach would be to have two schema files, one which only contains the schema descriptions from RFC 4524 and one with the missing schema descriptions from RFC 1274 with the latter obviously being dependent on the former. >> IPR notice: >> This patch file is derived from OpenLDAP Software and RFC 4524 and RFC >> 1274. All of the modifications to OpenLDAP Software represented in the >> attached file were developed by Michael Ströder <michael(a)stroeder.com>. >> I have not assigned rights and/or interest in this work to any party. > > While this notice of origin is fine, you did not include a rights > statement. I, Michael Ströder, hereby place the modified schema file cosine.schema attached to ITS#6151 (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. Ciao, Michael.

1 0

(ITS#6162) hexadecimal log levels are not recognized in configuration
by jonathan＠phillipoux.net 08 Jun '09

08 Jun '09

Full_Name: Jonathan Clarke Version: RE24 and HEAD OS: irrelevant URL: ftp://ftp.openldap.org/incoming/jonathan-clarke-bconfig-20090608.patch Submission from: (NULL) (80.65.230.146) The slapd-config(5) and slapd.conf(5) man pages state: olcLogLevel: <integer> [...] The desired log level can be input as a single integer that combines the (ORed) desired levels, both in decimal or in hexadecimal notation [...] as a list of integers (that are ORed internally), or as a list of the names that are shown between brackets, This is not the case. Integers and names (strings) are accepted, but hex notation is refused, with, from slapd.conf: /opt/openldap-RE24/etc/openldap/slapd.conf: line 10: <loglevel> unable to parse level "0x40" And using ldapmodify on cn=config: ldap_modify: Other (e.g., implementation specific) error (80) additional info: <olcLogLevel> unable to parse level Hexadecimal values are, however, accepted as arguments to the -d argument to slapd on the command line. The above patch fixes bconfig.c to accept hex values. On a side note, according to man strtol(3), this also means that loglevels can be typed in octal, for the more masochist among us :)

1 0

Re: (ITS#6161) test058-syncrepl-asymmetric failed (exit 6)
by michael＠stroeder.com 07 Jun '09

07 Jun '09

Download content of directory testrun/ here: http://www.stroeder.com/temp/openldap/its6161-testrun.tar.gz I cannot reproduce this within directory tests/. It usually ends with this message: ERROR: Entry not removed on central search! Race error found after 1 of 10 iterations Found 3 errors >>>>>> Exiting with a false success status for now

1 0

(ITS#6161) test058-syncrepl-asymmetric failed (exit 6)
by michael＠stroeder.com 07 Jun '09

07 Jun '09

Full_Name: Michael Ströder Version: RE24 OS: openSUSE Linux 11.1 URL: Submission from: (NULL) (84.163.113.91) Found 6 errors >>>>> ./scripts/test058-syncrepl-asymmetric failed (exit 6) make[2]: *** [hdb-mod] Error 6 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

1 0

Re: (ITS#6104) race condition with cancel operation
by h.b.furuseth＠usit.uio.no 05 Jun '09

05 Jun '09

Hrmph, the placement of the 'so->s_op->o_abandon = 1;' which I wanted to move out of the mutex lock derives from syncprov.c rev 1.20 commented "Fix abandon sequencing":-( -- Hallvard

1 0

Re: (ITS#6160) slapadd man page doesn't note indexing
by quanah＠zimbra.com 05 Jun '09

05 Jun '09

--On Friday, June 05, 2009 9:25 PM +0100 Gavin Henry <gavin.henry(a)gmail.com> wrote: > Is there a SEE ALSO? > > Will check and amend. Regardless of SEE ALSO, it should note that it indexes the database while adding it. ;) SEE ALSO ldap(3), ldif(5), slapcat(8), ldapadd(1), slapd(8) Should probably have slapindex in the SEE ALSO as well. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6160) slapadd man page doesn't note indexing
by gavin.henry＠gmail.com 05 Jun '09

05 Jun '09

Is there a SEE ALSO? Will check and amend. On 05/06/2009, quanah(a)openldap.org <quanah(a)openldap.org> wrote: > Full_Name: Quanah Gibson-Mount > Version: 2.4.16 > OS: NA > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (75.111.29.239) > > > The man page for slapadd does not note that it also performs indexing while > adding the database. While this is fairly obvious to those of us > experienced > with using OpenLDAP, it is non-obvious to new users. > > > -- Sent from my mobile device http://www.suretecsystems.com/services/openldap/ http://www.suretectelecom.com

1 0

(ITS#6160) slapadd man page doesn't note indexing
by quanah＠OpenLDAP.org 05 Jun '09

05 Jun '09

Full_Name: Quanah Gibson-Mount Version: 2.4.16 OS: NA URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.111.29.239) The man page for slapadd does not note that it also performs indexing while adding the database. While this is fairly obvious to those of us experienced with using OpenLDAP, it is non-obvious to new users.

1 0

Re: (ITS#6157) unAbandonable operations aren't.
by h.b.furuseth＠usit.uio.no 04 Jun '09

04 Jun '09

Caught cancel(cancel) and cancel/abandon(abandon/bind/unbind), partly fixed cancel(cn=config update) problem, without doing this: > Suggested partual fix - add this possible value for o_cancel: > #define SLAP_CANCEL_INVALID 0x04 /* like 0 but prevents Cancel */ Still need something that to fix cancel(cn=config update) completely. syncrepl/syncprov, starttls not yet addressed. Also cancel(cancel) still behaves in a non-RFC way. Correct fix would require resetting o_abandon, which seems unsafe. Who knows what has already reacted to it. Will update this patch for the remaining issues later: > Something like this: > http://folk.uio.no/hbf/OpenLDAP/cancel-cancel.txt -- Hallvard

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs