openldap-bugs

openldap-bugs@openldap.org

1 participants
20959 discussions

Re: (ITS#4713) test030-relay broken in HEAD
by quanah＠stanford.edu 16 Oct '06

16 Oct '06

--On Monday, October 16, 2006 5:41 AM +0000 quanah(a)stanford.edu wrote: > I'll see if I can get a core from it. Never mind, I found the problem in slapd.1.out: /usr/local/build/ldap-head-20061015/servers/slapd/.libs/lt-slapd: relocation error: ../servers/slapd/back-meta/.libs/back_meta-2-devel.so.0: undefined symbol: ldap_back_proxy_authz_ctrl Sounds like something isn't being linked right, or something isn't declared right in the back-meta build. --Quanah -- Quanah Gibson-Mount Principal Software Developer ITS/Shared Application Services Stanford University GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html

1 0

Re: (ITS#4713) test030-relay broken in HEAD
by quanah＠stanford.edu 16 Oct '06

16 Oct '06

--On Monday, October 16, 2006 5:38 AM +0000 ando(a)sys-net.it wrote: > quanah(a)stanford.edu wrote: >> When running test030-relay, I get a failure. >> > works just fine here, on Linux 32 bit and Solaris 64 bit >> Basic output shows: >> >> Using meta backend... >> >> Starting slapd on TCP/IP port 9011... >> Using ldapsearch to check that slapd is running... >> Using ldapadd to populate the database... >> Searching base="dc=example,dc=com"... >> Searching base="o=Example,c=US"... >> Search failed (255)! >> ./scripts/test030-relay: line 79: kill: (20796) - No such process >> > Sounds like slapd either stopped or crashed; anything relevant from > slapd's logs (or any core dump around)? >> The ldapsearch.out file shows: >> > snip... >> # searching base="o=Example,c=US"... >> ldap_result: Can't contact LDAP server (-1) >> > This is not much indicative of the reason of the failure; see above. > Note that Saturday 14 I made sort of a mess in HEAD with daemon.c, which > I only noticed and fixed late Sunday 15; please make sure you're using > the correct files from HEAD. It is HEAD as of now, i.e., I retrieved it this evening. ;) I'll see if I can get a core from it. --Quanah -- Quanah Gibson-Mount Principal Software Developer ITS/Shared Application Services Stanford University GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html

1 0

Re: (ITS#4713) test030-relay broken in HEAD
by ando＠sys-net.it 16 Oct '06

16 Oct '06

quanah(a)stanford.edu wrote: > When running test030-relay, I get a failure. > works just fine here, on Linux 32 bit and Solaris 64 bit > Basic output shows: > > Using meta backend... > > Starting slapd on TCP/IP port 9011... > Using ldapsearch to check that slapd is running... > Using ldapadd to populate the database... > Searching base="dc=example,dc=com"... > Searching base="o=Example,c=US"... > Search failed (255)! > ./scripts/test030-relay: line 79: kill: (20796) - No such process > Sounds like slapd either stopped or crashed; anything relevant from slapd's logs (or any core dump around)? > The ldapsearch.out file shows: > snip... > # searching base="o=Example,c=US"... > ldap_result: Can't contact LDAP server (-1) > This is not much indicative of the reason of the failure; see above. Note that Saturday 14 I made sort of a mess in HEAD with daemon.c, which I only noticed and fixed late Sunday 15; please make sure you're using the correct files from HEAD. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.n.c. Via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ------------------------------------------ Office: +39.02.23998309 Mobile: +39.333.4963172 Email: pierangelo.masarati(a)sys-net.it ------------------------------------------

1 0

(ITS#4713) test030-relay broken in HEAD
by quanah＠stanford.edu 16 Oct '06

16 Oct '06

Full_Name: Quanah Gibson-Mount Version: HEAD 2006/10/15 OS: Linux 2.6 64-bit URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (171.66.155.86) When running test030-relay, I get a failure. Basic output shows: Using meta backend... Starting slapd on TCP/IP port 9011... Using ldapsearch to check that slapd is running... Using ldapadd to populate the database... Searching base="dc=example,dc=com"... Searching base="o=Example,c=US"... Search failed (255)! ./scripts/test030-relay: line 79: kill: (20796) - No such process The ldapsearch.out file shows: objectClass: OpenLDAPperson cn: Ursula Hampster sn: Hampster uid: uham title: Secretary, UM Alumni Association postalAddress: Alumni Association $ 111 Maple St $ Anytown, MI 48109 seeAlso: cn=All Staff,ou=Groups,dc=example,dc=com homePostalAddress: 123 Anystreet $ Anytown, MI 48104 mail: uham(a)mail.alumni.example.com homePhone: +1 313 555 8421 pager: +1 313 555 2844 facsimileTelephoneNumber: +1 313 555 9700 telephoneNumber: +1 313 555 5331 # searching base="o=Example,c=US"... ldap_result: Can't contact LDAP server (-1)

1 0

Re: (ITS#4712) test007: slapd crashes
by michael＠stroeder.com 16 Oct '06

16 Oct '06

Pierangelo Masarati wrote: > Michael Ströder wrote: > >> Yes, I learned this (again) on Friday. ;-) >> >> export CFLAGS="-g" > > Note that this does not disable optimization (AFAIK); I'd place an > explicit CFLAGS="-g -O0". Unfortunately this does not help. >> But it still does not work. >> > But in any case that doesn't seem to be the issue. What gcc are you > using? SuSE Linux 10.1 $ gcc -v Using built-in specs. Target: i586-suse-linux Configured with: ../configure --enable-threads=posix --prefix=/usr --with-local-prefix=/usr/local --infodir=/usr/share/info --mandir=/usr/share/man --libdir=/usr/lib --libexecdir=/usr/lib --enable-languages=c,c++,objc,fortran,java,ada --enable-checking=release --with-gxx-include-dir=/usr/include/c++/4.1.0 --enable-ssp --disable-libssp --enable-java-awt=gtk --enable-gtk-cairo --disable-libjava-multilib --with-slibdir=/lib --with-system-zlib --enable-shared --enable-__cxa_atexit --enable-libstdcxx-allocator=new --without-system-libunwind --with-cpu=generic --host=i586-suse-linux Thread model: posix gcc version 4.1.0 (SUSE Linux) Ciao, Michael.

1 0

Re: (ITS#4712) test007: slapd crashes
by quanah＠stanford.edu 16 Oct '06

16 Oct '06

--On Sunday, October 15, 2006 10:08 PM +0000 hyc(a)symas.com wrote: > ando(a)sys-net.it wrote: >> Michael Str?der wrote: >>> Yes, I learned this (again) on Friday. ;-) >>> >>> export CFLAGS="-g" >>> >> Note that this does not disable optimization (AFAIK); I'd place an >> explicit CFLAGS="-g -O0". > > No, the default without any -O flag is no optimization. > >>> But it still does not work. >>> >> But in any case that doesn't seem to be the issue. What gcc are you >> using? I currently use RedHat's, either gcc version 3.4.6 20060404 (Red >> Hat 3.4.6-3) or gcc version 4.1.0 20060515 (Red Hat 4.1.0-18). Note >> that I don't assume this could have an impact on your issue. > > I think Michael just has a corrupt build tree. The previous issue he > reported was cleared up by running "make clean" in the back-bdb and > back-monitor directories, then rebuilding. I suspect just doing a "make > clean" from the top level and rebuilding would clear up the rest. HEAD from today builds just fine for me, with BDB 4.5, and test007 passes. OL 2.3.27 doesn't work with BDB 4.5, although I (so far) have not been able to track down a BDB 4.5 specific commit to HEAD. --Quanah -- Quanah Gibson-Mount Principal Software Developer ITS/Shared Application Services Stanford University GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html

1 0

Re: (ITS#4712) test007: slapd crashes
by hyc＠symas.com 15 Oct '06

15 Oct '06

ando(a)sys-net.it wrote: > Michael Ströder wrote: >> Yes, I learned this (again) on Friday. ;-) >> >> export CFLAGS="-g" >> > Note that this does not disable optimization (AFAIK); I'd place an > explicit CFLAGS="-g -O0". No, the default without any -O flag is no optimization. >> But it still does not work. >> > But in any case that doesn't seem to be the issue. What gcc are you > using? I currently use RedHat's, either gcc version 3.4.6 20060404 (Red > Hat 3.4.6-3) or gcc version 4.1.0 20060515 (Red Hat 4.1.0-18). Note > that I don't assume this could have an impact on your issue. I think Michael just has a corrupt build tree. The previous issue he reported was cleared up by running "make clean" in the back-bdb and back-monitor directories, then rebuilding. I suspect just doing a "make clean" from the top level and rebuilding would clear up the rest. This does point out a bug in the slapd Makefile; for dynamic backends it appears to not remake the backend directories if they have already been built once. I'll look into that... -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/

1 0

Re: (ITS#4712) test007: slapd crashes
by ando＠sys-net.it 15 Oct '06

15 Oct '06

Michael Ströder wrote: > Yes, I learned this (again) on Friday. ;-) > > export CFLAGS="-g" > Note that this does not disable optimization (AFAIK); I'd place an explicit CFLAGS="-g -O0". > But it still does not work. > But in any case that doesn't seem to be the issue. What gcc are you using? I currently use RedHat's, either gcc version 3.4.6 20060404 (Red Hat 3.4.6-3) or gcc version 4.1.0 20060515 (Red Hat 4.1.0-18). Note that I don't assume this could have an impact on your issue. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.n.c. Via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ------------------------------------------ Office: +39.02.23998309 Mobile: +39.333.4963172 Email: pierangelo.masarati(a)sys-net.it ------------------------------------------

1 0

Re: (ITS#4712) test007: slapd crashes
by michael＠stroeder.com 15 Oct '06

15 Oct '06

Pierangelo Masarati wrote: > > this backtrace looks weird, because: > - bconfig.c:2734 is not in config_replica() in HEAD right now, and, > according to cvsweb, the last commit to bconfig.c occurred 4 weeks ago > (unless you modified that file yourself) The only modifications to my HEAD source tree are happening through cvs up -RdP . > You should really cross-check what you're debugging, or something else > is going berserk. Maybe try without optimization? Yes, I learned this (again) on Friday. ;-) export CFLAGS="-g" But it still does not work. Ciao, Michael.

1 0

Re: (ITS#4702) out-of-memory on huge DB ?
by Paolo.Rossi.con＠h3g.it 15 Oct '06

15 Oct '06

> > slapcat -f slapd.conf > > > So you understand that without the -l flag to slapcat, you are > writing to > stdout instead of a file? Is it possible that is what is causing > slapcat > to crash? > I used slapcat without -l for two reasons: usually i slapcat pipiing in gzip the stdout so i can realtime gzip the ldif: slapcat -f slapd.conf | gzip > out.ldif.gz and also because on 32 bit slapcat, avoid the 2GB filsize limit on output ldif > > slapcat -f slapd.conf here the full command was: slapcat -f slapd.conf > fulldump.ldif However, I've retry with "-l file" on 32 bit linux and solaris (why not ?) Linux stops when reached 2GB file out; but there was a little bit of memory available and the allocation rate was similar to previous trials In Solaris, due to speed up the test I've ulimit -d 1024000, reached 2 GB file without stops itself (usually solaris continues, simply throws out additional data) then some time later: ch_malloc of 16392 bytes failed ch_malloc.c:57: failed assertion `0' Abort (core dumped) with a while/loop ps, last line was: PID RSS VSZ %MEM TIME STIME COMMAND 18246 1652488 1656144 41.1 31:23 09:22:35 slapcat > On my linux 2.6 system (64 bit), with a 2.5 million entry db, which > is: > > ldap00:/var/lib/ldap/slamd/64-2.5mil-db42# du -h *.bdb > 84M cn.bdb > 618M dn2id.bdb > 85M employeeNumber.bdb > 3.2G id2entry.bdb > 3.7M objectClass.bdb > 85M uid.bdb this runs I've tried a db like: ldap@labsLDAP:/TEST_producer/openldap-data> du -h *.bdb 3,0M testCode.bdb 2,9G dn2id.bdb 600M entryCSN.bdb 545M entryUUID.bdb 15G id2entry.bdb 1,9M objectClass.bdb 270M testId.bdb > So, that does mean one thing -- It definitely outgrew the 366MB of BDB > cache defined. On the other hand, once it reached its max size, it > stayed > steady there until completion was reached. > In my trials, instead, allocation never stops :( Perhaps due to a greater DB ? Paolo

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs