openldap-bugs June 2007

openldap-bugs@openldap.org

35 participants
170 discussions

RE: (ITS#5026) LDAP Search very slow > 2mins
by andy.yip＠newworldtel.com 21 Jun '07

21 Jun '07

Dear sir, We found the ldap search is slow running. Please advise how to fine tune the database. I am not sure adding cache size or perform db_recover will solve the problem Regards, Andy -----Original Message----- From: Hallvard Breien Furuseth [mailto:h.b.furuseth@usit.uio.no] Sent: Wednesday, June 20, 2007 10:39 PM To: Yip S C, Andy (NS NWT) Cc: openldap-its(a)openldap.org Subject: Re: (ITS#5026) LDAP Search very slow > 2mins Please take this to the mailinglist openldap-software(a)openldap.org. The ITS system is for bug reports, feature requests etc. This ITS will be closed. Note however that there never was an OpenLDAP version 1.8.8.7. So I wonder if your trouble is with a Sun LDAP server instead. -- Regards, Hallvard

1 0

Re: (ITS#4839) syncrepl-related tests fail randomly
by hyc＠symas.com 21 Jun '07

21 Jun '07

h.b.furuseth(a)usit.uio.no wrote: > ando(a)sys-net.it writes: >> I'm seeing occasional failures of syncrepl-related tests in HEAD. In >> case of test043, results differend once, but after repeating the test >> everything went smoth. > > Six HEAD/test043-delta-syncrepl failures in a row. Producer and > consumer databases differ. RedHat Linux, i686. Logs etc from testrun: > ftp://ftp.openldap.org/incoming/Hallvard-Furuseth-070621.tgz > Strange, I saw some failures last week but with current HEAD it just works. -- -- Howard Chu Chief Architect, 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#4839) syncrepl-related tests fail randomly
by h.b.furuseth＠usit.uio.no 21 Jun '07

21 Jun '07

ando(a)sys-net.it writes: > I'm seeing occasional failures of syncrepl-related tests in HEAD. In > case of test043, results differend once, but after repeating the test > everything went smoth. Six HEAD/test043-delta-syncrepl failures in a row. Producer and consumer databases differ. RedHat Linux, i686. Logs etc from testrun: ftp://ftp.openldap.org/incoming/Hallvard-Furuseth-070621.tgz -- Regards, Hallvard

1 0

Re: (ITS#4959) replica seg faults if syncrepl searchbase =""
by ali.pouya＠free.fr 21 Jun '07

21 Jun '07

h.b.furuseth(a)usit.uio.no wrote : >That's from ITS#4975: The code was broken for builds without TLS. >It's been fixed in HEAD. Does it work now? Hi Hallvard, Yes I confirm that the problem with TLS compilation is fixed now. But the main problem of this ITS still remains (replica seg faults if syncrepl searchbase =""). Sorry for this late answer. Best regards Ali

1 0

Re: (ITS#5022) ldappasswd crash consumer slapd with some loglevels
by gao＠schrodinger.com 20 Jun '07

20 Jun '07

Pierangelo Masarati wrote: > Simon Gao wrote: > > >> OpenLDAP-2.3.36 fixed the problem. Now at loglevel 0, 512, 256, slapd no >> longer crashes. You can go ahead close 5022 and 5023. >> > > OK. Then I think the different behavior at different loglevel was > actually a side effect of something related to ITS#4964. > > >> Should I also update provider to 2.3.36? >> > > AFAIK, no. Please make sure that the password change, besides > succeeding, is correctly replicated. While fixing ITS#4964, a companion > bug in the provider was discovered, but it appeared to be related to > code development that's not in the 2.3 release (ITS#4973). > > Replications works fine. I tries changing password 5 or 6 times, replication worked each time. I will hold on upgrading provider for now. Thanks again. Simon

1 0

Re: (ITS#5022) ldappasswd crash consumer slapd with some loglevels
by ando＠sys-net.it 20 Jun '07

20 Jun '07

Simon Gao wrote: > OpenLDAP-2.3.36 fixed the problem. Now at loglevel 0, 512, 256, slapd no > longer crashes. You can go ahead close 5022 and 5023. OK. Then I think the different behavior at different loglevel was actually a side effect of something related to ITS#4964. > Should I also update provider to 2.3.36? AFAIK, no. Please make sure that the password change, besides succeeding, is correctly replicated. While fixing ITS#4964, a companion bug in the provider was discovered, but it appeared to be related to code development that's not in the 2.3 release (ITS#4973). Cheers, p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. 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#5022) ldappasswd crash consumer slapd with some loglevels
by gao＠schrodinger.com 20 Jun '07

20 Jun '07

Pierangelo Masarati wrote: > gao(a)schrodinger.com wrote: > > >> slapd: result.c:364: send_ldap_response: Assertion `rs->sr_err != 0x0a' >> failed. >> > > __Could__ be the same as ITS#4964, which was fixed in OpenLDAP 2.3.36 > just released, apart from depending on the log level, which I definitely > consider odd. > > Can you check if the problem persists with the latest release? > > OpenLDAP-2.3.36 fixed the problem. Now at loglevel 0, 512, 256, slapd no longer crashes. You can go ahead close 5022 and 5023. Should I also update provider to 2.3.36? Thanks, Simon

1 0

RE: slapd+pcache keeps crashing on FreeBSD 6.2 (ITS#4841)
by imriz＠co.zahav.net.il 20 Jun '07

20 Jun '07

Hi Howard, I've reduced the threads to 4 (number of cpus), and I still get frequent coredumps: #0 0xa83ba58a in strcasecmp () from /lib/libc.so.6 [New Thread 0x9e31800 (LWP 100335)] [New Thread 0x81eb500 (LWP 100316)] [New Thread 0x8188a00 (LWP 100185)] [New Thread 0x81cff00 (LWP 100146)] [New Thread 0x81c9800 (LWP 100069)] [New Thread 0x813a000 (LWP 100626)] (gdb) bt #0 0xa83ba58a in strcasecmp () from /lib/libc.so.6 #1 0x080a93d0 in an_find (a=0xa81b6f0, s=0x830b2a4) at ad.c:842 #2 0x080d5a41 in add_filter_attrs (op=0xa78a800, new_attrs=0xbf1fc8c4, attrs=0x81863e0, filter_attrs=0x830b27c, fattr_cnt=3, fattr_got_oc=0) at pcache.c:1140 #3 0x080d6260 in pcache_op_search (op=0xa78a800, rs=0xbf1fcd70) at pcache.c:1313 #4 0x080c8401 in overlay_op_walk (op=0xa78a800, rs=0xbf1fcd70, which=op_search, oi=0x813ae00, on=0x813af00) at backover.c:498 #5 0x080c861d in over_op_func (op=0xa78a800, rs=0xbf1fcd70, which=op_search) at backover.c:560 #6 0x080c869a in over_op_search (op=0xa78a800, rs=0xbf1fcd70) at backover.c:582 #7 0x0806ec33 in fe_op_search (op=0xa78a800, rs=0xbf1fcd70) at search.c:355 #8 0x0806e752 in do_search (op=0xa78a800, rs=0xbf1fcd70) at search.c:217 #9 0x0806c1b7 in connection_operation (ctx=0xbf1fce00, arg_v=0xa78a800) at connection.c:1133 #10 0xa816be00 in ldap_int_thread_pool_wrapper (xpool=0x8148340) at tpool.c:478 #11 0xa830e5cf in pthread_create () from /usr/lib/libthr.so.2 #12 0x00000000 in ?? () > -----Original Message----- > From: Howard Chu [mailto:hyc@symas.com] > Sent: Wednesday, June 20, 2007 10:02 AM > To: Imri Zvik > Cc: openldap-its(a)openldap.org > Subject: Re: slapd+pcache keeps crashing on FreeBSD 6.2 (ITS#4841) > > It appears that your system has simply run out of memory, most likely > because > you have 34 active threads in the process. That's far too many threads > for a > typical 32 bit machine. > > Imri Zvik ( Smile ) wrote: > > I have new tar.gz file ready, this time with unstripped binaries: > > http://mariska.inter.net.il/~imriz/slapd-crash-10042007.tar.gz > > > > root@cemetery:~$ ldd /usr/local/libexec/slapd > > /usr/local/libexec/slapd: > > libldap_r-2.3-releng.so.2 => > > /usr/local/lib/libldap_r-2.3-releng.so.2 (0xa8161000) > > liblber-2.3-releng.so.2 => > > /usr/local/lib/liblber-2.3-releng.so.2 (0xa81a1000) > > libssl.so.4 => /usr/lib/libssl.so.4 (0xa81b7000) > > libcrypto.so.4 => /lib/libcrypto.so.4 (0xa81e5000) > > libfetch.so.4 => /usr/lib/libfetch.so.4 (0xa82d8000) > > libcom_err.so.3 => /usr/lib/libcom_err.so.3 (0xa82e5000) > > libcrypt.so.3 => /lib/libcrypt.so.3 (0xa82e7000) > > libltdl.so.4 => /usr/local/lib/libltdl.so.4 (0xa82ff000) > > libpthread.so.2 => /usr/lib/libthr.so.2 (0xa8307000) > > libc.so.6 => /lib/libc.so.6 (0xa8319000) > > root@cemetery:~$ file /usr/local/libexec/slapd > > /usr/local/libexec/slapd: ELF 32-bit LSB executable, Intel 80386, > > version 1 (FreeBSD), dynamically linked (uses shared libs), not > stripped > > > > Please let me know if there is anything else you need, > > > > --imriz > > > > > >> -----Original Message----- > >> From: Howard Chu [mailto:hyc@symas.com] > >> Sent: Tuesday, April 03, 2007 12:42 AM > >> To: Imri Zvik ( Smile ) > >> Cc: openldap-its(a)openldap.org > >> Subject: Re: slapd+pcache keeps crashing on FreeBSD 6.2 (ITS#4841) > >> > >> imriz(a)co.zahav.net.il wrote: > >>> Sure. New core dumps and binary file is at > >>> http://mariska.inter.net.il/~imriz/slapd-core.tar.gz > >> The slapd in this snapshot was stripped so no debug symbols are > >> present. > >> Please be sure to use an unstripped binary. > >> > >> Also, since you're also loading libldap_r, liblber, back-ldap, back- > >> bdb, > >> back-meta, and back-ldbm dynamically, you'll need to include those > >> modules in the tarball. (Also with debug and unstripped.) > >> > >> Although at this point I'm wondering why you're using back-ldbm, > which > >> has been deprecated for quite a long time. > >> > >>> Please notice that the previous dump was from FreeBSD ports > > (OpenLDAP > >>> version 2.3.33). > >>> > >>> This one was fetched from the CVS (OPENLDAP_REL_ENG_2_3), with the > >>> following configure options: > >>> > >>> ./configure --with-threads=posix --with-tls=openssl --enable- > dynamic > >>> --without-cyrus-sasl --enable-modules --localstatedir=/var/ > >>> db --enable-ldbm=mod --enable-crypt --enable-lmpasswd --enable- > >> ldap=mod > >>> --enable-meta=mod --enable-rewrite --enable-null=mod --enabl > >>> e-monitor=mod --enable-proxycache --disable-syncprov > > --enable-bdb=mod > >>> --enable-hdb=mod --enable-dbm-api=berkeley --disable-slurpd -- > >>> prefix=/usr/local --enable-debug > >>> > >>> > >>> -----Original Message----- > >>> From: Howard Chu [mailto:openldap-its@OpenLDAP.org] > >>> Sent: Tuesday, February 13, 2007 1:14 AM > >>> To: Imri Zvik > >>> Subject: Re: slapd+pcache keeps crashing on FreeBSD 6.2 (ITS#4841) > >>> > >>> It looks like this core is from a binary without debug symbols > >> present, > >>> can you > >>> recompile with debugging enabled and get a new stack trace and core > >>> file? > > -- > -- Howard Chu > Chief Architect, 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#5026) LDAP Search very slow > 2mins
by h.b.furuseth＠usit.uio.no 20 Jun '07

20 Jun '07

Please take this to the mailinglist openldap-software(a)openldap.org. The ITS system is for bug reports, feature requests etc. This ITS will be closed. Note however that there never was an OpenLDAP version 1.8.8.7. So I wonder if your trouble is with a Sun LDAP server instead. -- Regards, Hallvard

1 0

Re: (ITS#4943) tpool.c pause vs. finish
by h.b.furuseth＠usit.uio.no 20 Jun '07

20 Jun '07

About context_reset() in pool_wrapper(): Yes, it works out. Anyway I completely lost that kfree functions may not lock ltp_mutex since it's already locked (again unless they go active). Will just document that they may not call functions which take a pool argument anyway - they can only use the context. Will also insert various asserts about how the pool should be used (pause/pause etc.) Another detail: tpool.c tracks task counts as 'long's, but pool_query() and pool_backload() return them in 'int's. Can use int counts instead and set a max pending limit of INT_MAX - LDAP_MAXTHR. -- Regards, Hallvard

1 0

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs June 2007