openldap-bugs

openldap-bugs@openldap.org

1 participants
20960 discussions

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

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

20 Jun '07

Full_Name: Andy Yip Version: 1.8.8.7 OS: Solaris 8 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (203.98.135.2) We found ldap_search runs very slow.We's like to know how to fine tune the database. Please help

1 0

Re: slapd+pcache keeps crashing on FreeBSD 6.2 (ITS#4841)
by hyc＠symas.com 20 Jun '07

20 Jun '07

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

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