Please test RE23 in preparation for OpenLDAP 2.3.41.
Thanks, Quanah+
--
Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration
Quanah Gibson-Mount wrote:
Please test RE23 in preparation for OpenLDAP 2.3.41.
Does not work for me on openSuSE 10.3.
Starting test000-rootdse ...
running defines.sh Starting slapd on TCP/IP port 9011... Using ldapsearch to retrieve the root DSE... Waiting 5 seconds for slapd to start... Waiting 5 seconds for slapd to start... Waiting 5 seconds for slapd to start... Waiting 5 seconds for slapd to start... Waiting 5 seconds for slapd to start... Waiting 5 seconds for slapd to start... ./scripts/test000-rootdse: line 66: kill: (4801) - No such process ldap_bind: Can't contact LDAP server (-1)
Test failed ./scripts/test000-rootdse failed (exit 1)
See logs in attachments.
Ciao, Michael.
ldap_bind: Can't contact LDAP server (-1)
Hallvard B Furuseth wrote:
Michael Ströder writes:
/home/michael/src/openldap/OPENLDAP_REL_ENG_2_3/openldap/servers/slapd/.libs/lt-slapd:
Symbol `ldap_int_global_options' has different size in shared object, consider re-linking
What ./configure options? Does make distclean and rebuild help?
I've attached the build script. It contains 'make distclean'. It fails no matter whether I compile with -O4 or -O0 (gcc version 4.2.1).
Ciao, Michael.
On Dienstag, 12. Februar 2008, Michael Ströder wrote:
Hallvard B Furuseth wrote:
Michael Ströder writes:
/home/michael/src/openldap/OPENLDAP_REL_ENG_2_3/openldap/servers/s lapd/.libs/lt-slapd:
Symbol `ldap_int_global_options' has different size in shared object, consider re-linking
What ./configure options? Does make distclean and rebuild help?
I've attached the build script. It contains 'make distclean'. It fails no matter whether I compile with -O4 or -O0 (gcc version 4.2.1).
Might that be caused by the missing "make depend" step?
Hallvard B Furuseth wrote:
Are there some non-Linux folks here who can test it? :-)
The Project's new build server is running, so we may be able to test x86 Solaris or FreeBSD soon.
Ralf Haferkamp wrote:
On Dienstag, 12. Februar 2008, Michael Ströder wrote:
Hallvard B Furuseth wrote:
Michael Ströder writes:
/home/michael/src/openldap/OPENLDAP_REL_ENG_2_3/openldap/servers/s lapd/.libs/lt-slapd:
Symbol `ldap_int_global_options' has different size in shared object, consider re-linking
What ./configure options? Does make distclean and rebuild help?
I've attached the build script. It contains 'make distclean'. It fails no matter whether I compile with -O4 or -O0 (gcc version 4.2.1).
Might that be caused by the missing "make depend" step?
Inserting 'make depend' into my build script does not help either. Note that the very same build script works with RE24 but not with 2.3.40. :-(
Any hint? Maybe something related to libtool?
Hmm, I noticed that RE24 is not built with dynamically loadable backends/overlays on my system although the parameters for ./configure requires that.
Ciao, Michael.
On Feb 12, 2008, at 9:43 AM, Hallvard B Furuseth wrote:
Are there some non-Linux folks here who can test it? :-)
I was going to say "Sure!" since I have a NetBSD host handy that I use for LDAP experiments among other things, but it seems that I can't make test002-populate work, for any release. Error occurs when authenticating the root DN -
do_bind: version=3 dn="cn=Manager,dc=example,dc=com" method=128 ==> bdb_bind: dn: cn=Manager,dc=example,dc=com bdb_dn2entry("cn=manager,dc=example,dc=com") => bdb_dn2id("dc=example,dc=com") <= bdb_dn2id: get failed: DB_NOTFOUND: No matching key/data pair found (-30990)
I must be missing something - config looks fine, the rootdn is specified as above. Database is valid, though empty as I guess expected.
Anyway, I need to move on to something else right now, and will probably have to wait until tomorrow before I get back to this.
Donn Cave, donn@u.washington.edu
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Quanah Gibson-Mount wrote:
Please test RE23 in preparation for OpenLDAP 2.3.41.
All regression tests passed on FreeBSD/amd64 7.0-RC2 with OPENLDAP_REL_ENG_2_3 tree as of Feb 12, 2008 11:00 PST.
Cheers, - -- Xin LI delphij@delphij.net http://www.delphij.net/ FreeBSD - The Power to Serve!
On Tue, 12 Feb 2008, Hallvard B Furuseth wrote:
Are there some non-Linux folks here who can test it? :-)
Tested both RE23 and RE24 on FreeBSD 6.2.
--On February 12, 2008 12:18:38 PM -0800 Donn Cave donn@u.washington.edu wrote:
On Feb 12, 2008, at 9:43 AM, Hallvard B Furuseth wrote:
Are there some non-Linux folks here who can test it? :-)
I was going to say "Sure!" since I have a NetBSD host handy
Thanks! Please make sure you sync as of this evening, as some reworking was done in 2.3 today to fix a few issues that showed up.
--Quanah
--
Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration
Michael Ströder writes:
Might that be caused by the missing "make depend" step?
If so make distclean (which he did use) would be broken. There are hosts which don't provide a way to do "make depend".
Any hint? Maybe something related to libtool?
Remove your CPPFLAGS and LDFLAGS. It's the -Wl,-R/usr/lib. That worked in OpenLDAP 2.2 but has been broken since 2.3.4 (the first 2.3 release). Links the libraries in /usr/lib instead of the ones you just built. Don't know if it's the Makefile or libtool.
I seem to remeber warnings in the gcc doc that you should not do -I/usr/include either, it overrides gcc's special version of some files. Or did, maybe they've worked around it since I saw that.
Hallvard B Furuseth wrote:
Michael Ströder writes:
Might that be caused by the missing "make depend" step?
If so make distclean (which he did use) would be broken. There are hosts which don't provide a way to do "make depend".
Any hint? Maybe something related to libtool?
Remove your CPPFLAGS and LDFLAGS. It's the -Wl,-R/usr/lib.
This gave me the right hint: I've removed the openSUSE RPM packages for the OpenLDAP client 2.3 libs and now it works. It works with RE24 though. Is this because of different versions of the shared libs?
Ralf, any way to avoid that yast always wants to re-install the RPM package openldap2-client? I've now added a file to /etc/ld.so.conf.d which points to the self-compiled installation /opt/openldap-RE23/lib. This used to work in former times. (Maybe your response off-list...)
Ciao, Michael.
Passes all tests on CentOS4.6 and CentOS5.1 (i686 and virtual machines)
Ing. Luca Scamoni Responsabile Ricerca e Sviluppo
SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 0382 573859 (137) Mobile: +39 347 1014425 Email: luca.scamoni@sys-net.it -----------------------------------
On NetBSD 3.1, test008-concurrency dies trying to allocate 8388608 bytes -
search_candidates: base="dc=example,dc=com" (0x00000001) scope=2 ch_malloc of 8388608 bytes failed assertion "0" failed: file "ch_malloc.c", line 57, function "ch_malloc"
#0 0xbd9980fb in kill () from /usr/lib/libc.so.12 #1 0xbda1917f in abort () from /usr/lib/libc.so.12 #2 0xbd9e309a in __assert13 () from /usr/lib/libc.so.12 #3 0x08077bce in ch_malloc (size=8388608) at ch_malloc.c:57 #4 0x080c18e6 in search_stack (op=0x8435000) at search.c:1008 #5 0x080c1c4d in search_candidates (op=0x8435000, rs=0xb8fffd58, e=0xb8f3fa58, locker=70, ids=0xb8f7fa88, scopes=0xb8f3fa88) at search.c:1094 #6 0x080c13d3 in bdb_search (op=0x8435000, rs=0xb8fffd58) at search.c:573 #7 0x0806390f in fe_op_search (op=0x8435000, rs=0xb8fffd58) at search.c:368 #8 0x08063195 in do_search (op=0x8435000, rs=0xb8fffd58) at search.c:217 #9 0x080617a8 in connection_operation (ctx=0xb8fffe28, arg_v=0x8435000) at connection.c:1084 #10 0x080619ae in connection_read_thread (ctx=0xb8fffe28, argv=0xa) at connection.c:1211 #11 0x0814f21c in ldap_int_thread_pool_wrapper (xpool=0x830a380) at tpool.c:625 #12 0xbda4917d in pthread_create () from /usr/lib/libpthread.so.0
search.c:1008 ret = ch_malloc( bdb->bi_search_stack_depth * BDB_IDL_UM_SIZE * sizeof( ID ) );
source acquired via cvs ca 10 AM PST - same failure with rel_eng_2_3 and rel_eng_2_4.
Also, same failure with test039-glue-ldap-concurrency - could be a pattern here.
Donn Cave, donn@u.washington.edu
On Tuesday 12 February 2008 19:43:28 Hallvard B Furuseth wrote:
Are there some non-Linux folks here who can test it? :-)
I consider myself a Linux person, but I do have a Solaris 10 / sparc64 box under my desk, if no-one else is testing Solaris 10 / sparc, I can go through the pain of getting it to compile OpenLDAP (or seeing if I can convince my solaris sparc build of rpm to build my usual SRPM).
We also have the odd Solaris 9 / Sparc 64, including one build host ...
Regards, Buchan
Buchan Milne wrote:
On Tuesday 12 February 2008 19:43:28 Hallvard B Furuseth wrote:
Are there some non-Linux folks here who can test it? :-)
I consider myself a Linux person, but I do have a Solaris 10 / sparc64 box under my desk, if no-one else is testing Solaris 10 / sparc, I can go through the pain of getting it to compile OpenLDAP (or seeing if I can convince my solaris sparc build of rpm to build my usual SRPM).
I still have temporary access to a Solaris 10 T5120. I'll give it a whirl. (Each core is pretty slow, but you can get pretty good build times with "make -j32")
Donn Cave wrote:
On NetBSD 3.1, test008-concurrency dies trying to allocate 8388608 bytes -
search_candidates: base="dc=example,dc=com" (0x00000001) scope=2 ch_malloc of 8388608 bytes failed assertion "0" failed: file "ch_malloc.c", line 57, function"ch_malloc"
Also, same failure with test039-glue-ldap-concurrency - could be a pattern here.
Yes, both tests would have similar behavior. It seems to me that this isn't anything unusual though. Does NetBSD default to a particular ulimit on datasize?
Buchan Milne wrote:
On Tuesday 12 February 2008 19:43:28 Hallvard B Furuseth wrote:
Are there some non-Linux folks here who can test it? :-)
I consider myself a Linux person, but I do have a Solaris 10 / sparc64 box under my desk, if no-one else is testing Solaris 10 / sparc, I can go through the pain of getting it to compile OpenLDAP (or seeing if I can convince my solaris sparc build of rpm to build my usual SRPM).
Of course I'm testing RE24 at the moment. Aside from ITS#5379 it built fine on Solaris 10 sparc64 with BDB 4.6.21. Will try RE23 when this round of tests completes.
On Feb 14, 2008, at 2:32 AM, Howard Chu wrote:
Donn Cave wrote:
On NetBSD 3.1, test008-concurrency dies trying to allocate 8388608 bytes -
search_candidates: base="dc=example,dc=com" (0x00000001) scope=2 ch_malloc of 8388608 bytes failed assertion "0" failed: file "ch_malloc.c", line 57, function"ch_malloc"
Also, same failure with test039-glue-ldap-concurrency - could be a pattern here.
Yes, both tests would have similar behavior. It seems to me that this isn't anything unusual though. Does NetBSD default to a particular ulimit on datasize?
$ ulimit -a core file size (blocks, -c) unlimited data seg size (kbytes, -d) 131072 file size (blocks, -f) unlimited max locked memory (kbytes, -l) 1279544 max memory size (kbytes, -m) 3838632 open files (-n) 64 pipe size (512 bytes, -p) 1 stack size (kbytes, -s) 2048 cpu time (seconds, -t) unlimited max user processes (-u) 160 virtual memory (kbytes, -v) 133120
The tests complete OK on 2_3 and 2_4, with data seg up to 1048576, max memory size unlimited, stack size 32768, virtual memory 1081344.
Donn Cave, donn@u.washington.edu
Donn Cave wrote:
On Feb 14, 2008, at 2:32 AM, Howard Chu wrote:
Donn Cave wrote:
On NetBSD 3.1, test008-concurrency dies trying to allocate 8388608 bytes -
search_candidates: base="dc=example,dc=com" (0x00000001) scope=2 ch_malloc of 8388608 bytes failed assertion "0" failed: file "ch_malloc.c", line 57, function"ch_malloc" Also, same failure with test039-glue-ldap-concurrency - could be a pattern here.
Yes, both tests would have similar behavior. It seems to me that this isn't anything unusual though. Does NetBSD default to a particular ulimit on datasize?
$ ulimit -a core file size (blocks, -c) unlimited data seg size (kbytes, -d) 131072 file size (blocks, -f) unlimited max locked memory (kbytes, -l) 1279544 max memory size (kbytes, -m) 3838632 open files (-n) 64 pipe size (512 bytes, -p) 1 stack size (kbytes, -s) 2048 cpu time (seconds, -t) unlimited max user processes (-u) 160 virtual memory (kbytes, -v) 133120
The tests complete OK on 2_3 and 2_4, with data seg up to 1048576, max memory size unlimited, stack size 32768, virtual memory 1081344.
Sounds ok. I also seem to recall test036 or test039 having problems on some Unix systems (AIX or HPUX IIRC) if the number of files wasn't at least 128 or so. (Since Linux defaults to 1024 this problem never came up there.) You shouldn't need to alter the stack limit; that only applies to the initial program stack and slapd does all its work in threads which each get their own explicitly allocated stack.
The pipe size is surprising, usually it's 1 page (4096 bytes). I guess that won't have any impact here though.
-
Aaron Richton -
Buchan Milne -
Dave Horsfall -
Donn Cave -
Gavin Henry -
Hallvard B Furuseth -
Howard Chu -
Luca Scamoni -
Michael Ströder -
Quanah Gibson-Mount -
Ralf Haferkamp -
Xin LI