- openldap-bugs - openldap.org

Re: (ITS#4839) syncrepl-related tests fail randomly
by luca＠OpenLDAP.org 25 Jun '07

25 Jun '07

hyc(a)symas.com wrote: > 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. > Nevermind. I just checked out a fresh copy from CVS and it works just fine. Maybe something fancy with some modifications I was testing. I'll have to check.

1 0

RE: (ITS#5026) LDAP Search very slow > 2mins
by quanah＠zimbra.com 22 Jun '07

22 Jun '07

--On Friday, June 22, 2007 6:55 AM +0000 andy.yip(a)newworldtel.com wrote: > 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 (a) This is not the place to discuss how to tune openldap (b) You have not indicated a valid OpenLDAP version, and in fact, give the impression that you are using Sun DS not OpenLDAP. That means *we* cannot help you. (c) If you *are* using OpenLDAP, go use openldap-software(a)openldap.org to ask your questions, as you were already told to do. Supply a *valid* OpenLDAP version. Further emails to this ITS will be ignored. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#4839) syncrepl-related tests fail randomly
by luca＠OpenLDAP.org 22 Jun '07

22 Jun '07

hyc(a)symas.com wrote: > 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. > > I just uploaded my test files ftp://ftp.openldap.org/incoming/Luca_Scamoni-070622.tgz The difference here is also in the modifyTimestamp and modifiersName...

1 0

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

(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

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

19 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? > > I will. Probably I will get back you tomorrow. Simon

1 0

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

19 Jun '07

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? 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 19 Jun '07

19 Jun '07

Quanah Gibson-Mount wrote: > --On Tuesday, June 19, 2007 9:38 PM -0700 Simon Gao > <gao(a)schrodinger.com> wrote: > >> I take back what I said in my last email. When compiled with "-ggdb", >> slapd on consumer server still crashes while running: > > Compile with -g, not -ggdb. > > And when you "make install", slapd generally gets stripped, which is > why there is still no really useful info. You need to run make > install STRIP="" > Yes, I generated first coredump with "-g". If "-ggdb" is not helpful, please forget it. I used "FEATURES="nostrip" emerge --buildpkgonly <package>" to compile new OpenLDAP binaries with "-g" option. Then untar it to a temp directory. This way there is no stripping occurred. So here is coredump when slapd is compile with "-g": ==================================================================================== # gdb /tmp/debug/usr/lib/openldap/slapd GNU gdb 6.6 Copyright (C) 2006 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i686-pc-linux-gnu"... Using host libthread_db library "/lib/libthread_db.so.1". (gdb) run -d 0 -u ldap -g ldap -h 'ldap:// ldaps://' Starting program: /tmp/debug/usr/lib/openldap/slapd -d 0 -u ldap -g ldap -h 'ldap:// ldaps://' [Thread debugging using libthread_db enabled] [New Thread -1213049168 (LWP 28621)] [New Thread -1240032368 (LWP 28624)] [New Thread -1248425072 (LWP 28625)] [New Thread -1256817776 (LWP 28626)] slapd: result.c:364: send_ldap_response: Assertion `rs->sr_err != 0x0a' failed. Program received signal SIGABRT, Aborted. [Switching to Thread -1248425072 (LWP 28625)] 0xbfffe402 in __kernel_vsyscall () (gdb) bt full #0 0xbfffe402 in __kernel_vsyscall () No symbol table info available. #1 0xb7b4f429 in raise () from /lib/libc.so.6 No symbol table info available. #2 0xb7b509d1 in abort () from /lib/libc.so.6 No symbol table info available. #3 0xb7b48e51 in __assert_fail () from /lib/libc.so.6 No symbol table info available. #4 0x080809c5 in send_ldap_response (op=0x827c760, rs=0xb59681b4) at result.c:364 berbuf = { buffer = "\002\000\001\000\000\000\000\000????\000\000\000\000\000\000\000\000\\Pv?\\Pv?8`v?<`v?\000\000\000\000H\212&\b", '\0' <repeats 211 times>, ialign = 65538, lalign = 65538, falign = 9.18382988e-41, dalign = 3.2380074297143616e-319, palign = 0x10002 <Address 0x10002 out of bounds>} ber = (BerElement *) 0xb5967a18 rc = <value optimized out> bytes = <value optimized out> __PRETTY_FUNCTION__ = "send_ldap_response" #5 0x08080caf in slap_send_ldap_extended (op=0x827c760, rs=0xb59681b4) at result.c:630 No locals. #6 0x080fa450 in ldap_chain_response (op=0x827c760, rs=0xb59681b4) ---Type <return> to continue, or q <return> to quit--- at chain.c:920 db = {bd_info = 0x820dc60, be_ctrls = "\000\001\001\001\000\000\001\000\001\000\001\001\001\000\001", '\0' <repeats 17 times>, "\001", be_flags = 37122, be_restrictops = 0, be_requires = 0, be_ssf_set = {sss_ssf = 0, sss_transport = 0, sss_tls = 0, sss_sasl = 0, sss_update_ssf = 0, sss_update_transport = 0, sss_update_tls = 0, sss_update_sasl = 0, sss_simple_bind = 0}, be_suffix = 0x820e308, be_nsuffix = 0x820e240, be_schemadn = {bv_len = 0, bv_val = 0x0}, be_schemandn = {bv_len = 0, bv_val = 0x0}, be_rootdn = { bv_len = 34, bv_val = 0x820e6d8 "cn=ldapadmin,dc=example,dc=com"}, be_rootndn = {bv_len = 34, bv_val = 0x820e718 "cn=ldapadmin,dc=example,dc=com"}, be_rootpw = { bv_len = 38, bv_val = 0x820e740 "{SSHA}f5kiigYucjOHoM0r9zDuwW0GjxVa9y1h"}, be_max_deref_depth = 15, be_def_limit = {lms_t_soft = 3600, lms_t_hard = 0, lms_s_soft = 3000, lms_s_hard = 0, lms_s_unchecked = -1, lms_s_pr = 0, lms_s_pr_hide = 0, lms_s_pr_total = 0}, be_limits = 0x0, be_acl = 0x81e2650, be_dfltaccess = ACL_READ, be_replica = 0x0, be_replogfile = 0x0, be_update_ndn = {bv_len = 0, bv_val = 0x0}, be_update_refs = 0x8211100, be_pending_csn_list = 0x8259318, be_pcl_mutex = { __data = {__lock = 0, __count = 0, __owner = 0, __kind = 0, __nusers = 0, { __spins = 0, __list = {__next = 0x0}}}, __size = '\0' <repeats 23 times>, __align = 0}, be_pcl_mutexp = 0x820e400, be_syncinfo = 0x8210fa0, be_pb = 0x0, be_cf_ocs = 0x81841e0, be_private = 0x820e438, be_next = {stqe_next = 0x0}} ---Type <return> to continue, or q <return> to quit--- lb = {lb_status = LDAP_CH_NONE, lb_lc = 0x820dd60, lb_op_f = 0, lb_depth = 0} sc = (slap_callback *) 0xb596811c sc2 = {sc_next = 0x0, sc_response = 0x80fa782 <ldap_chain_cb_response>, sc_cleanup = 0, sc_private = 0xb5967cbc} rc = 80 text = 0x0 matched = 0x0 ref = (BerVarray) 0x8279b18 sr_err = 10 sr_type = REP_EXTENDED #7 0x080c73e5 in over_back_response (op=0x827c760, rs=0xb59681b4) at backover.c:236 on = (slap_overinst *) 0x820dc60 rc = 0 be = (BackendDB *) 0x820e330 db = {bd_info = 0x820dc60, be_ctrls = "\000\001\001\001\000\000\001\000\001\000\001\001\001\000\001", '\0' <repeats 17 times>, "\001", be_flags = 37122, be_restrictops = 0, be_requires = 0, be_ssf_set = {sss_ssf = 0, sss_transport = 0, sss_tls = 0, sss_sasl = 0, sss_update_ssf = 0, sss_update_transport = 0, sss_update_tls = 0, sss_update_sasl = 0, sss_simple_bind = 0}, be_suffix = 0x820e308, be_nsuffix = 0x820e240, be_schemadn = {bv_len = 0, ---Type <return> to continue, or q <return> to quit--- bv_val = 0x0}, be_schemandn = {bv_len = 0, bv_val = 0x0}, be_rootdn = { bv_len = 34, bv_val = 0x820e6d8 "cn=ldapadmin,dc=example,dc=com"}, be_rootndn = {bv_len = 34, bv_val = 0x820e718 "cn=ldapadmin,dc=example,dc=com"}, be_rootpw = { bv_len = 38, bv_val = 0x820e740 "{SSHA}f5kiigYucjOHoM0r9zDuwW0GjxVa9y1h"}, be_max_deref_depth = 15, be_def_limit = {lms_t_soft = 3600, lms_t_hard = 0, lms_s_soft = 3000, lms_s_hard = 0, lms_s_unchecked = -1, lms_s_pr = 0, lms_s_pr_hide = 0, lms_s_pr_total = 0}, be_limits = 0x0, be_acl = 0x81e2650, be_dfltaccess = ACL_READ, be_replica = 0x0, be_replogfile = 0x0, be_update_ndn = {bv_len = 0, bv_val = 0x0}, be_update_refs = 0x8211100, be_pending_csn_list = 0x8259318, be_pcl_mutex = { __data = {__lock = 0, __count = 0, __owner = 0, __kind = 0, __nusers = 0, { __spins = 0, __list = {__next = 0x0}}}, __size = '\0' <repeats 23 times>, __align = 0}, be_pcl_mutexp = 0x820e400, be_syncinfo = 0x8210fa0, be_pb = 0x0, be_cf_ocs = 0x81841e0, be_private = 0x820e438, be_next = {stqe_next = 0x0}} #8 0x080803ee in send_ldap_response (op=0x827c760, rs=0xb59681b4) at result.c:303 sc = (slap_callback *) 0xb596811c sc_prev = (slap_callback **) 0xb5967f48 sc_next = (slap_callback *) 0x0 berbuf = { buffer = "\035\000\000\000\000\000\000\000????\000\000\000\000????\006-\v\bh?'\b?~\226?\030\223%\b\000\000\000\000\000\000\000\000\b\021!\b", '\0' <repeats 13---Type <return> to continue, or q <return> to quit--- times>, "? \bh?'\b\030\233'\b\020?'\b8? \b\000\000\000\000\034\201\226?us\f\b", '\0' <repeats 28 times>, "`?'\b?\201\226?h?'\b\n\000\000\000|?'\b\204?'\b`?'\bC\025\n\b<Pv?H\212&\b\000\000\000\000????\205?\023\b", '\0' <repeats 24 times>, "?\201\226?\234?'\b\224?'\b", '\0' <repeats 16 times>, "\027\000\000\000??'\b\001\000\000\000d\201\226?\000"..., ialign = 29, lalign = 29, falign = 4.06376555e-44, dalign = 1.432790372939615e-322, palign = 0x1d <Address 0x1d out of bounds>} ber = <value optimized out> rc = -1024 bytes = <value optimized out> __PRETTY_FUNCTION__ = "send_ldap_response" #9 0x08080caf in slap_send_ldap_extended (op=0x827c760, rs=0xb59681b4) at result.c:630 No locals. #10 0x0809ff84 in fe_extended (op=0x827c760, rs=0xb59681b4) at extended.c:230 bd = (BackendDB *) 0xb596801c ext = (struct extop_list *) 0x81af248 #11 0x080c74d0 in overlay_op_walk (op=0x827c760, rs=0xb59681b4, which=op_extended, oi=0x820db60, on=0x820dc60) at backover.c:508 sc_next = <value optimized out> rc = 32768 #12 0x080c783b in over_op_func (op=0x827c760, rs=0xb59681b4, which=op_extended) at backover.c:560 oi = (slap_overinfo *) 0x820db60 ---Type <return> to continue, or q <return> to quit--- on = (slap_overinst *) 0x820dc60 be = (BackendDB *) 0x8188200 db = {bd_info = 0x8188100, be_ctrls = "\000", '\001' <repeats 13 times>, '\0' <repeats 18 times>, be_flags = 769, be_restrictops = 0, be_requires = 0, be_ssf_set = { sss_ssf = 0, sss_transport = 0, sss_tls = 0, sss_sasl = 0, sss_update_ssf = 0, sss_update_transport = 0, sss_update_tls = 0, sss_update_sasl = 0, sss_simple_bind = 0}, be_suffix = 0x81dec78, be_nsuffix = 0x81deca0, be_schemadn = {bv_len = 12, bv_val = 0x8211140 "cn=Subschema"}, be_schemandn = {bv_len = 12, bv_val = 0x8210f00 "cn=subschema"}, be_rootdn = {bv_len = 0, bv_val = 0x0}, be_rootndn = {bv_len = 0, bv_val = 0x0}, be_rootpw = { bv_len = 0, bv_val = 0x0}, be_max_deref_depth = 0, be_def_limit = { lms_t_soft = 3600, lms_t_hard = 0, lms_s_soft = 500, lms_s_hard = 0, lms_s_unchecked = -1, lms_s_pr = 0, lms_s_pr_hide = 0, lms_s_pr_total = 0}, be_limits = 0x0, be_acl = 0x81e2650, be_dfltaccess = ACL_READ, be_replica = 0x0, be_replogfile = 0x0, be_update_ndn = {bv_len = 0, bv_val = 0x0}, be_update_refs = 0x0, be_pending_csn_list = 0x0, be_pcl_mutex = {__data = {__lock = 0, __count = 0, __owner = 0, __kind = 0, __nusers = 0, {__spins = 0, __list = {__next = 0x0}}}, __size = '\0' <repeats 23 times>, __align = 0}, be_pcl_mutexp = 0x0, be_syncinfo = 0x0, be_pb = 0x0, be_cf_ocs = 0x81826c4, be_private = 0x0, be_next = {stqe_next = 0x81dfff0}} cb = {sc_next = 0x0, sc_response = 0x80c7375 <over_back_response>, ---Type <return> to continue, or q <return> to quit--- sc_cleanup = 0, sc_private = 0x820db60} rc = 0 __PRETTY_FUNCTION__ = "over_op_func" #13 0x080a04b8 in do_extended (op=0x827c760, rs=0xb59681b4) at extended.c:180 reqdata = {bv_len = 22, bv_val = 0x827c9d8 "0\024\201\bpiThid6i"} len = 22 #14 0x0806f701 in connection_operation (ctx=0xb5968238, arg_v=0x827c760) at connection.c:1133 curelm = <value optimized out> rc = <value optimized out> rs = {sr_type = REP_EXTENDED, sr_tag = 120, sr_msgid = 2, sr_err = 10, sr_matched = 0x0, sr_text = 0x0, sr_ref = 0x0, sr_ctrls = 0x0, sr_un = { sru_sasl = {r_sasldata = 0x0}, sru_extended = {r_rspoid = 0x0, r_rspdata = 0x0}, sru_search = {r_entry = 0x0, r_attr_flags = 0, r_operational_attrs = 0x0, r_attrs = 0x0, r_nentries = 0, r_v2ref = 0x0}}, sr_flags = 32} tag = 119 opidx = SLAP_OP_EXTENDED conn = (Connection *) 0xb616b598 memctx = (void *) 0x8268a48 memctx_null = (void *) 0x0 __PRETTY_FUNCTION__ = "connection_operation" #15 0xb7f83bb1 in ?? () from /usr/lib/libldap_r-2.3.so.0 No symbol table info available. ---Type <return> to continue, or q <return> to quit--- #16 0xb5968238 in ?? () No symbol table info available. #17 0x0827c760 in ?? () No symbol table info available. #18 0xb7fb0024 in ?? () from /usr/lib/libldap_r-2.3.so.0 No symbol table info available. #19 0xb5968238 in ?? () No symbol table info available. #20 0xb7fb0020 in ?? () from /usr/lib/libldap_r-2.3.so.0 No symbol table info available. #21 0x081cb96c in ?? () No symbol table info available. #22 0x081cb954 in ?? () No symbol table info available. #23 0x00000000 in ?? () No symbol table info available. ============================================================================================ Simon

1 0

Re: (ITS#5022) ldappasswd crash consumer slapd with some loglevels
by quanah＠zimbra.com 19 Jun '07

19 Jun '07

--On Tuesday, June 19, 2007 9:38 PM -0700 Simon Gao <gao(a)schrodinger.com> wrote: > I take back what I said in my last email. When compiled with "-ggdb", > slapd on consumer server still crashes while running: Compile with -g, not -ggdb. And when you "make install", slapd generally gets stripped, which is why there is still no really useful info. You need to run make install STRIP="" --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

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

19 Jun '07

I take back what I said in my last email. When compiled with "-ggdb", slapd on consumer server still crashes while running: ldappasswd -v -H ldap://ldap2.example.com -D "uid=user,ou=people,dc=example,dc=com" -W -S -x -A Here is coredump with "-ggdb" if helpful: ======================================================================================= # gdb /tmp/debug/usr/lib/openldap/slapd GNU gdb 6.6 Copyright (C) 2006 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i686-pc-linux-gnu"... Using host libthread_db library "/lib/libthread_db.so.1". (gdb) run -d 0 -u ldap -g ldap -h 'ldap:// ldaps://' Starting program: /tmp/debug/usr/lib/openldap/slapd -d 0 -u ldap -g ldap -h 'ldap:// ldaps://' [Thread debugging using libthread_db enabled] [New Thread -1213368656 (LWP 6060)] [New Thread -1240351856 (LWP 6063)] [New Thread -1248744560 (LWP 6064)] [New Thread -1257137264 (LWP 6065)] slapd: result.c:364: send_ldap_response: Assertion `rs->sr_err != 0x0a' failed. Program received signal SIGABRT, Aborted. [Switching to Thread -1257137264 (LWP 6065)] 0xbfffe402 in __kernel_vsyscall () (gdb) bt full #0 0xbfffe402 in __kernel_vsyscall () No symbol table info available. #1 0xb7b01429 in raise () from /lib/libc.so.6 No symbol table info available. #2 0xb7b029d1 in abort () from /lib/libc.so.6 No symbol table info available. #3 0xb7afae51 in __assert_fail () from /lib/libc.so.6 No symbol table info available. #4 0x080809c5 in send_ldap_response (op=0x82640d8, rs=0xb51191b4) at result.c:364 berbuf = { buffer = "\002\000\001\000\000\000\000\000????\000\000\000\000\000\000\000\000\\\200\201?\\\200\201?8\220\201?<\220\201?\000\000\000\000?_%\b", '\0' <repeats 211 times>, ialign = 65538, lalign = 65538, falign = 9.18382988e-41, dalign = 3.2380074297143616e-319, palign = 0x10002 <Address 0x10002 out of bounds>} ber = (BerElement *) 0xb5118a18 rc = <value optimized out> bytes = <value optimized out> __PRETTY_FUNCTION__ = "send_ldap_response" #5 0x08080caf in slap_send_ldap_extended (op=0x82640d8, rs=0xb51191b4) at result.c:630 No locals. #6 0x080fa450 in ldap_chain_response (op=0x82640d8, rs=0xb51191b4) ---Type <return> to continue, or q <return> to quit--- at chain.c:920 db = {bd_info = 0x820dc60, be_ctrls = "\000\001\001\001\000\000\001\000\001\000\001\001\001\000\001", '\0' <repeats 17 times>, "\001", be_flags = 37122, be_restrictops = 0, be_requires = 0, be_ssf_set = {sss_ssf = 0, sss_transport = 0, sss_tls = 0, sss_sasl = 0, sss_update_ssf = 0, sss_update_transport = 0, sss_update_tls = 0, sss_update_sasl = 0, sss_simple_bind = 0}, be_suffix = 0x820e308, be_nsuffix = 0x820e240, be_schemadn = {bv_len = 0, bv_val = 0x0}, be_schemandn = {bv_len = 0, bv_val = 0x0}, be_rootdn = { bv_len = 34, bv_val = 0x820e6d8 "cn=ldapadmin,dc=example,dc=com"}, be_rootndn = {bv_len = 34, bv_val = 0x820e718 "cn=ldapadmin,dc=example,dc=com"}, be_rootpw = { bv_len = 38, bv_val = 0x820e740 "{SSHA}*******************************"}, be_max_deref_depth = 15, be_def_limit = {lms_t_soft = 3600, lms_t_hard = 0, lms_s_soft = 3000, lms_s_hard = 0, lms_s_unchecked = -1, lms_s_pr = 0, lms_s_pr_hide = 0, lms_s_pr_total = 0}, be_limits = 0x0, be_acl = 0x81e2650, be_dfltaccess = ACL_READ, be_replica = 0x0, be_replogfile = 0x0, be_update_ndn = {bv_len = 0, bv_val = 0x0}, be_update_refs = 0x8211100, be_pending_csn_list = 0x8259318, be_pcl_mutex = { __data = {__lock = 0, __count = 0, __owner = 0, __kind = 0, __nusers = 0, { __spins = 0, __list = {__next = 0x0}}}, __size = '\0' <repeats 23 times>, __align = 0}, be_pcl_mutexp = 0x820e400, be_syncinfo = 0x8210fa0, be_pb = 0x0, be_cf_ocs = 0x81841e0, be_private = 0x820e438, be_next = {stqe_next = 0x0}} ---Type <return> to continue, or q <return> to quit--- lb = {lb_status = LDAP_CH_NONE, lb_lc = 0x820dd60, lb_op_f = 0, lb_depth = 0} sc = (slap_callback *) 0xb511911c sc2 = {sc_next = 0x0, sc_response = 0x80fa782 <ldap_chain_cb_response>, sc_cleanup = 0, sc_private = 0xb5118cbc} rc = 80 text = 0x0 matched = 0x0 ref = (BerVarray) 0x8266fd0 sr_err = 10 sr_type = REP_EXTENDED #7 0x080c73e5 in over_back_response (op=0x82640d8, rs=0xb51191b4) at backover.c:236 on = (slap_overinst *) 0x820dc60 rc = 0 be = (BackendDB *) 0x820e330 db = {bd_info = 0x820dc60, be_ctrls = "\000\001\001\001\000\000\001\000\001\000\001\001\001\000\001", '\0' <repeats 17 times>, "\001", be_flags = 37122, be_restrictops = 0, be_requires = 0, be_ssf_set = {sss_ssf = 0, sss_transport = 0, sss_tls = 0, sss_sasl = 0, sss_update_ssf = 0, sss_update_transport = 0, sss_update_tls = 0, sss_update_sasl = 0, sss_simple_bind = 0}, be_suffix = 0x820e308, be_nsuffix = 0x820e240, be_schemadn = {bv_len = 0, ---Type <return> to continue, or q <return> to quit--- bv_val = 0x0}, be_schemandn = {bv_len = 0, bv_val = 0x0}, be_rootdn = { bv_len = 34, bv_val = 0x820e6d8 "cn=ldapadmin,dc=example,dc=com"}, be_rootndn = {bv_len = 34, bv_val = 0x820e718 "cn=ldapadmin,dc=example,dc=com"}, be_rootpw = { bv_len = 38, bv_val = 0x820e740 "{SSHA}********************************"}, be_max_deref_depth = 15, be_def_limit = {lms_t_soft = 3600, lms_t_hard = 0, lms_s_soft = 3000, lms_s_hard = 0, lms_s_unchecked = -1, lms_s_pr = 0, lms_s_pr_hide = 0, lms_s_pr_total = 0}, be_limits = 0x0, be_acl = 0x81e2650, be_dfltaccess = ACL_READ, be_replica = 0x0, be_replogfile = 0x0, be_update_ndn = {bv_len = 0, bv_val = 0x0}, be_update_refs = 0x8211100, be_pending_csn_list = 0x8259318, be_pcl_mutex = { __data = {__lock = 0, __count = 0, __owner = 0, __kind = 0, __nusers = 0, { __spins = 0, __list = {__next = 0x0}}}, __size = '\0' <repeats 23 times>, __align = 0}, be_pcl_mutexp = 0x820e400, be_syncinfo = 0x8210fa0, be_pb = 0x0, be_cf_ocs = 0x81841e0, be_private = 0x820e438, be_next = {stqe_next = 0x0}} #8 0x080803ee in send_ldap_response (op=0x82640d8, rs=0xb51191b4) at result.c:303 sc = (slap_callback *) 0xb511911c sc_prev = (slap_callback **) 0xb5118f48 sc_next = (slap_callback *) 0x0 berbuf = { buffer = "\035\000\000\000\000\000\000\000????\000\000\000\000????\006-\v\b??%\b?\216\021?\030\223%\b\000\000\000\000\000\000\000\000\b\021!\b", '\0' <repeats---Type <return> to continue, or q <return> to quit--- 13 times>, "? \b??%\b?o&\b\230?'\b8? \b\000\000\000\000\034\221\021?us\f\b", '\0' <repeats 28 times>, "?@&\b?\221\021???%\b\n\000\000\000?@&\b?@&\b?@&\bC\025\n\b<\200\201??_%\b\000\000\000\000????\205?\023\b", '\0' <repeats 24 times>, "?\221\021?\024A&\b\fA&\b", '\0' <repeats 16 times>, "\027\000\000\000??'\b\001\000\000\000d\221\021?\000"..., ialign = 29, lalign = 29, falign = 4.06376555e-44, dalign = 1.432790372939615e-322, palign = 0x1d <Address 0x1d out of bounds>} ber = <value optimized out> rc = -1024 bytes = <value optimized out> __PRETTY_FUNCTION__ = "send_ldap_response" #9 0x08080caf in slap_send_ldap_extended (op=0x82640d8, rs=0xb51191b4) at result.c:630 No locals. #10 0x0809ff84 in fe_extended (op=0x82640d8, rs=0xb51191b4) at extended.c:230 bd = (BackendDB *) 0xb511901c ext = (struct extop_list *) 0x81af248 #11 0x080c74d0 in overlay_op_walk (op=0x82640d8, rs=0xb51191b4, which=op_extended, oi=0x820db60, on=0x820dc60) at backover.c:508 sc_next = <value optimized out> rc = 32768 #12 0x080c783b in over_op_func (op=0x82640d8, rs=0xb51191b4, which=op_extended) at backover.c:560 oi = (slap_overinfo *) 0x820db60 on = (slap_overinst *) 0x820dc60 ---Type <return> to continue, or q <return> to quit--- be = (BackendDB *) 0x8188200 db = {bd_info = 0x8188100, be_ctrls = "\000", '\001' <repeats 13 times>, '\0' <repeats 18 times>, be_flags = 769, be_restrictops = 0, be_requires = 0, be_ssf_set = { sss_ssf = 0, sss_transport = 0, sss_tls = 0, sss_sasl = 0, sss_update_ssf = 0, sss_update_transport = 0, sss_update_tls = 0, sss_update_sasl = 0, sss_simple_bind = 0}, be_suffix = 0x81dec78, be_nsuffix = 0x81deca0, be_schemadn = {bv_len = 12, bv_val = 0x8211140 "cn=Subschema"}, be_schemandn = {bv_len = 12, bv_val = 0x8210f00 "cn=subschema"}, be_rootdn = {bv_len = 0, bv_val = 0x0}, be_rootndn = {bv_len = 0, bv_val = 0x0}, be_rootpw = { bv_len = 0, bv_val = 0x0}, be_max_deref_depth = 0, be_def_limit = { lms_t_soft = 3600, lms_t_hard = 0, lms_s_soft = 500, lms_s_hard = 0, lms_s_unchecked = -1, lms_s_pr = 0, lms_s_pr_hide = 0, lms_s_pr_total = 0}, be_limits = 0x0, be_acl = 0x81e2650, be_dfltaccess = ACL_READ, be_replica = 0x0, be_replogfile = 0x0, be_update_ndn = {bv_len = 0, bv_val = 0x0}, be_update_refs = 0x0, be_pending_csn_list = 0x0, be_pcl_mutex = {__data = {__lock = 0, __count = 0, __owner = 0, __kind = 0, __nusers = 0, {__spins = 0, __list = {__next = 0x0}}}, __size = '\0' <repeats 23 times>, __align = 0}, be_pcl_mutexp = 0x0, be_syncinfo = 0x0, be_pb = 0x0, be_cf_ocs = 0x81826c4, be_private = 0x0, be_next = {stqe_next = 0x81dfff0}} cb = {sc_next = 0x0, sc_response = 0x80c7375 <over_back_response>, sc_cleanup = 0, sc_private = 0x820db60} ---Type <return> to continue, or q <return> to quit--- rc = 0 __PRETTY_FUNCTION__ = "over_op_func" #13 0x080a04b8 in do_extended (op=0x82640d8, rs=0xb51191b4) at extended.c:180 reqdata = {bv_len = 22, bv_val = 0x827bbc0 "0\024\201\bpiThid6i"} len = 22 #14 0x0806f701 in connection_operation (ctx=0xb5119238, arg_v=0x82640d8) at connection.c:1133 curelm = <value optimized out> rc = <value optimized out> rs = {sr_type = REP_EXTENDED, sr_tag = 120, sr_msgid = 2, sr_err = 10, sr_matched = 0x0, sr_text = 0x0, sr_ref = 0x0, sr_ctrls = 0x0, sr_un = { sru_sasl = {r_sasldata = 0x0}, sru_extended = {r_rspoid = 0x0, r_rspdata = 0x0}, sru_search = {r_entry = 0x0, r_attr_flags = 0, r_operational_attrs = 0x0, r_attrs = 0x0, r_nentries = 0, r_v2ref = 0x0}}, sr_flags = 32} tag = 119 opidx = SLAP_OP_EXTENDED conn = (Connection *) 0xb611d598 memctx = (void *) 0x8255fb8 memctx_null = (void *) 0x0 __PRETTY_FUNCTION__ = "connection_operation" #15 0xb7f35bb1 in ?? () from /usr/lib/libldap_r-2.3.so.0 No symbol table info available. #16 0xb5119238 in ?? () ---Type <return> to continue, or q <return> to quit--- No symbol table info available. #17 0x082640d8 in ?? () No symbol table info available. #18 0xb7f62024 in ?? () from /usr/lib/libldap_r-2.3.so.0 No symbol table info available. #19 0xb5119238 in ?? () No symbol table info available. #20 0xb7f62020 in ?? () from /usr/lib/libldap_r-2.3.so.0 No symbol table info available. #21 0x081cb96c in ?? () No symbol table info available. #22 0x081cb954 in ?? () No symbol table info available. #23 0x00000000 in ?? () No symbol table info available. =================================================================================================== Simon

1 0

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

19 Jun '07

Quanah Gibson-Mount wrote: > > > --On June 19, 2007 10:19:15 PM +0000 gao(a)schrodinger.com wrote: >> Program received signal SIGABRT, Aborted. >> [Switching to Thread -1249219696 (LWP 7710)] >> 0xbfffe402 in __kernel_vsyscall () >> (gdb) bt full >> # 0 0xbfffe402 in __kernel_vsyscall () >> No symbol table info available. >> # 1 0xb7a8d429 in raise () from /lib/libc.so.6 >> No symbol table info available. >> # 2 0xb7a8e9d1 in abort () from /lib/libc.so.6 >> No symbol table info available. >> # 3 0xb7a86e51 in __assert_fail () from /lib/libc.so.6 >> No symbol table info available. >> # 4 0x080809c5 in send_ldap_response () >> No symbol table info available. >> # 5 0x0000000a in ?? () >> No symbol table info available. >> # 6 0x08150731 in ?? () >> No symbol table info available. >> # 7 0x08150731 in ?? () >> No symbol table info available. >> # 8 0xb58a61b4 in ?? () >> No symbol table info available. >> # 9 0xb58a5cac in ?? () >> No symbol table info available. >> # 10 0x00000000 in ?? () >> No symbol table info available. > > > Fairly worthless. You need to compile with -g and not strip the binary. Alright, I believe I am getting closer with this: ==================================================================================== # gdb /tmp/debug/usr/lib/openldap/slapd GNU gdb 6.6 Copyright (C) 2006 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i686-pc-linux-gnu"... Using host libthread_db library "/lib/libthread_db.so.1". (gdb) run -d 0 -u ldap -g ldap -h 'ldap:// ldaps://' Starting program: /tmp/debug/usr/lib/openldap/slapd -d 0 -u ldap -g ldap -h 'ldap:// ldaps://' [Thread debugging using libthread_db enabled] [New Thread -1213049168 (LWP 28621)] [New Thread -1240032368 (LWP 28624)] [New Thread -1248425072 (LWP 28625)] [New Thread -1256817776 (LWP 28626)] slapd: result.c:364: send_ldap_response: Assertion `rs->sr_err != 0x0a' failed. Program received signal SIGABRT, Aborted. [Switching to Thread -1248425072 (LWP 28625)] 0xbfffe402 in __kernel_vsyscall () (gdb) bt full #0 0xbfffe402 in __kernel_vsyscall () No symbol table info available. #1 0xb7b4f429 in raise () from /lib/libc.so.6 No symbol table info available. #2 0xb7b509d1 in abort () from /lib/libc.so.6 No symbol table info available. #3 0xb7b48e51 in __assert_fail () from /lib/libc.so.6 No symbol table info available. #4 0x080809c5 in send_ldap_response (op=0x827c760, rs=0xb59681b4) at result.c:364 berbuf = { buffer = "\002\000\001\000\000\000\000\000????\000\000\000\000\000\000\000\000\\Pv?\\Pv?8`v?<`v?\000\000\000\000H\212&\b", '\0' <repeats 211 times>, ialign = 65538, lalign = 65538, falign = 9.18382988e-41, dalign = 3.2380074297143616e-319, palign = 0x10002 <Address 0x10002 out of bounds>} ber = (BerElement *) 0xb5967a18 rc = <value optimized out> bytes = <value optimized out> __PRETTY_FUNCTION__ = "send_ldap_response" #5 0x08080caf in slap_send_ldap_extended (op=0x827c760, rs=0xb59681b4) at result.c:630 No locals. #6 0x080fa450 in ldap_chain_response (op=0x827c760, rs=0xb59681b4) ---Type <return> to continue, or q <return> to quit--- at chain.c:920 db = {bd_info = 0x820dc60, be_ctrls = "\000\001\001\001\000\000\001\000\001\000\001\001\001\000\001", '\0' <repeats 17 times>, "\001", be_flags = 37122, be_restrictops = 0, be_requires = 0, be_ssf_set = {sss_ssf = 0, sss_transport = 0, sss_tls = 0, sss_sasl = 0, sss_update_ssf = 0, sss_update_transport = 0, sss_update_tls = 0, sss_update_sasl = 0, sss_simple_bind = 0}, be_suffix = 0x820e308, be_nsuffix = 0x820e240, be_schemadn = {bv_len = 0, bv_val = 0x0}, be_schemandn = {bv_len = 0, bv_val = 0x0}, be_rootdn = { bv_len = 34, bv_val = 0x820e6d8 "cn=ldapadmin,dc=example,dc=com"}, be_rootndn = {bv_len = 34, bv_val = 0x820e718 "cn=ldapadmin,dc=example,dc=com"}, be_rootpw = { bv_len = 38, bv_val = 0x820e740 "{SSHA}f5kiigYucjOHoM0r9zDuwW0GjxVa9y1h"}, be_max_deref_depth = 15, be_def_limit = {lms_t_soft = 3600, lms_t_hard = 0, lms_s_soft = 3000, lms_s_hard = 0, lms_s_unchecked = -1, lms_s_pr = 0, lms_s_pr_hide = 0, lms_s_pr_total = 0}, be_limits = 0x0, be_acl = 0x81e2650, be_dfltaccess = ACL_READ, be_replica = 0x0, be_replogfile = 0x0, be_update_ndn = {bv_len = 0, bv_val = 0x0}, be_update_refs = 0x8211100, be_pending_csn_list = 0x8259318, be_pcl_mutex = { __data = {__lock = 0, __count = 0, __owner = 0, __kind = 0, __nusers = 0, { __spins = 0, __list = {__next = 0x0}}}, __size = '\0' <repeats 23 times>, __align = 0}, be_pcl_mutexp = 0x820e400, be_syncinfo = 0x8210fa0, be_pb = 0x0, be_cf_ocs = 0x81841e0, be_private = 0x820e438, be_next = {stqe_next = 0x0}} ---Type <return> to continue, or q <return> to quit--- lb = {lb_status = LDAP_CH_NONE, lb_lc = 0x820dd60, lb_op_f = 0, lb_depth = 0} sc = (slap_callback *) 0xb596811c sc2 = {sc_next = 0x0, sc_response = 0x80fa782 <ldap_chain_cb_response>, sc_cleanup = 0, sc_private = 0xb5967cbc} rc = 80 text = 0x0 matched = 0x0 ref = (BerVarray) 0x8279b18 sr_err = 10 sr_type = REP_EXTENDED #7 0x080c73e5 in over_back_response (op=0x827c760, rs=0xb59681b4) at backover.c:236 on = (slap_overinst *) 0x820dc60 rc = 0 be = (BackendDB *) 0x820e330 db = {bd_info = 0x820dc60, be_ctrls = "\000\001\001\001\000\000\001\000\001\000\001\001\001\000\001", '\0' <repeats 17 times>, "\001", be_flags = 37122, be_restrictops = 0, be_requires = 0, be_ssf_set = {sss_ssf = 0, sss_transport = 0, sss_tls = 0, sss_sasl = 0, sss_update_ssf = 0, sss_update_transport = 0, sss_update_tls = 0, sss_update_sasl = 0, sss_simple_bind = 0}, be_suffix = 0x820e308, be_nsuffix = 0x820e240, be_schemadn = {bv_len = 0, ---Type <return> to continue, or q <return> to quit--- bv_val = 0x0}, be_schemandn = {bv_len = 0, bv_val = 0x0}, be_rootdn = { bv_len = 34, bv_val = 0x820e6d8 "cn=ldapadmin,dc=example,dc=com"}, be_rootndn = {bv_len = 34, bv_val = 0x820e718 "cn=ldapadmin,dc=example,dc=com"}, be_rootpw = { bv_len = 38, bv_val = 0x820e740 "{SSHA}f5kiigYucjOHoM0r9zDuwW0GjxVa9y1h"}, be_max_deref_depth = 15, be_def_limit = {lms_t_soft = 3600, lms_t_hard = 0, lms_s_soft = 3000, lms_s_hard = 0, lms_s_unchecked = -1, lms_s_pr = 0, lms_s_pr_hide = 0, lms_s_pr_total = 0}, be_limits = 0x0, be_acl = 0x81e2650, be_dfltaccess = ACL_READ, be_replica = 0x0, be_replogfile = 0x0, be_update_ndn = {bv_len = 0, bv_val = 0x0}, be_update_refs = 0x8211100, be_pending_csn_list = 0x8259318, be_pcl_mutex = { __data = {__lock = 0, __count = 0, __owner = 0, __kind = 0, __nusers = 0, { __spins = 0, __list = {__next = 0x0}}}, __size = '\0' <repeats 23 times>, __align = 0}, be_pcl_mutexp = 0x820e400, be_syncinfo = 0x8210fa0, be_pb = 0x0, be_cf_ocs = 0x81841e0, be_private = 0x820e438, be_next = {stqe_next = 0x0}} #8 0x080803ee in send_ldap_response (op=0x827c760, rs=0xb59681b4) at result.c:303 sc = (slap_callback *) 0xb596811c sc_prev = (slap_callback **) 0xb5967f48 sc_next = (slap_callback *) 0x0 berbuf = { buffer = "\035\000\000\000\000\000\000\000????\000\000\000\000????\006-\v\bh?'\b?~\226?\030\223%\b\000\000\000\000\000\000\000\000\b\021!\b", '\0' <repeats 13---Type <return> to continue, or q <return> to quit--- times>, "? \bh?'\b\030\233'\b\020?'\b8? \b\000\000\000\000\034\201\226?us\f\b", '\0' <repeats 28 times>, "`?'\b?\201\226?h?'\b\n\000\000\000|?'\b\204?'\b`?'\bC\025\n\b<Pv?H\212&\b\000\000\000\000????\205?\023\b", '\0' <repeats 24 times>, "?\201\226?\234?'\b\224?'\b", '\0' <repeats 16 times>, "\027\000\000\000??'\b\001\000\000\000d\201\226?\000"..., ialign = 29, lalign = 29, falign = 4.06376555e-44, dalign = 1.432790372939615e-322, palign = 0x1d <Address 0x1d out of bounds>} ber = <value optimized out> rc = -1024 bytes = <value optimized out> __PRETTY_FUNCTION__ = "send_ldap_response" #9 0x08080caf in slap_send_ldap_extended (op=0x827c760, rs=0xb59681b4) at result.c:630 No locals. #10 0x0809ff84 in fe_extended (op=0x827c760, rs=0xb59681b4) at extended.c:230 bd = (BackendDB *) 0xb596801c ext = (struct extop_list *) 0x81af248 #11 0x080c74d0 in overlay_op_walk (op=0x827c760, rs=0xb59681b4, which=op_extended, oi=0x820db60, on=0x820dc60) at backover.c:508 sc_next = <value optimized out> rc = 32768 #12 0x080c783b in over_op_func (op=0x827c760, rs=0xb59681b4, which=op_extended) at backover.c:560 oi = (slap_overinfo *) 0x820db60 ---Type <return> to continue, or q <return> to quit--- on = (slap_overinst *) 0x820dc60 be = (BackendDB *) 0x8188200 db = {bd_info = 0x8188100, be_ctrls = "\000", '\001' <repeats 13 times>, '\0' <repeats 18 times>, be_flags = 769, be_restrictops = 0, be_requires = 0, be_ssf_set = { sss_ssf = 0, sss_transport = 0, sss_tls = 0, sss_sasl = 0, sss_update_ssf = 0, sss_update_transport = 0, sss_update_tls = 0, sss_update_sasl = 0, sss_simple_bind = 0}, be_suffix = 0x81dec78, be_nsuffix = 0x81deca0, be_schemadn = {bv_len = 12, bv_val = 0x8211140 "cn=Subschema"}, be_schemandn = {bv_len = 12, bv_val = 0x8210f00 "cn=subschema"}, be_rootdn = {bv_len = 0, bv_val = 0x0}, be_rootndn = {bv_len = 0, bv_val = 0x0}, be_rootpw = { bv_len = 0, bv_val = 0x0}, be_max_deref_depth = 0, be_def_limit = { lms_t_soft = 3600, lms_t_hard = 0, lms_s_soft = 500, lms_s_hard = 0, lms_s_unchecked = -1, lms_s_pr = 0, lms_s_pr_hide = 0, lms_s_pr_total = 0}, be_limits = 0x0, be_acl = 0x81e2650, be_dfltaccess = ACL_READ, be_replica = 0x0, be_replogfile = 0x0, be_update_ndn = {bv_len = 0, bv_val = 0x0}, be_update_refs = 0x0, be_pending_csn_list = 0x0, be_pcl_mutex = {__data = {__lock = 0, __count = 0, __owner = 0, __kind = 0, __nusers = 0, {__spins = 0, __list = {__next = 0x0}}}, __size = '\0' <repeats 23 times>, __align = 0}, be_pcl_mutexp = 0x0, be_syncinfo = 0x0, be_pb = 0x0, be_cf_ocs = 0x81826c4, be_private = 0x0, be_next = {stqe_next = 0x81dfff0}} cb = {sc_next = 0x0, sc_response = 0x80c7375 <over_back_response>, ---Type <return> to continue, or q <return> to quit--- sc_cleanup = 0, sc_private = 0x820db60} rc = 0 __PRETTY_FUNCTION__ = "over_op_func" #13 0x080a04b8 in do_extended (op=0x827c760, rs=0xb59681b4) at extended.c:180 reqdata = {bv_len = 22, bv_val = 0x827c9d8 "0\024\201\bpiThid6i"} len = 22 #14 0x0806f701 in connection_operation (ctx=0xb5968238, arg_v=0x827c760) at connection.c:1133 curelm = <value optimized out> rc = <value optimized out> rs = {sr_type = REP_EXTENDED, sr_tag = 120, sr_msgid = 2, sr_err = 10, sr_matched = 0x0, sr_text = 0x0, sr_ref = 0x0, sr_ctrls = 0x0, sr_un = { sru_sasl = {r_sasldata = 0x0}, sru_extended = {r_rspoid = 0x0, r_rspdata = 0x0}, sru_search = {r_entry = 0x0, r_attr_flags = 0, r_operational_attrs = 0x0, r_attrs = 0x0, r_nentries = 0, r_v2ref = 0x0}}, sr_flags = 32} tag = 119 opidx = SLAP_OP_EXTENDED conn = (Connection *) 0xb616b598 memctx = (void *) 0x8268a48 memctx_null = (void *) 0x0 __PRETTY_FUNCTION__ = "connection_operation" #15 0xb7f83bb1 in ?? () from /usr/lib/libldap_r-2.3.so.0 No symbol table info available. ---Type <return> to continue, or q <return> to quit--- #16 0xb5968238 in ?? () No symbol table info available. #17 0x0827c760 in ?? () No symbol table info available. #18 0xb7fb0024 in ?? () from /usr/lib/libldap_r-2.3.so.0 No symbol table info available. #19 0xb5968238 in ?? () No symbol table info available. #20 0xb7fb0020 in ?? () from /usr/lib/libldap_r-2.3.so.0 No symbol table info available. #21 0x081cb96c in ?? () No symbol table info available. #22 0x081cb954 in ?? () No symbol table info available. #23 0x00000000 in ?? () No symbol table info available. ============================================================================================ The coredump is generated when running following against one consumer slapd daemon: ldappasswd -v -H ldap://ldap2.example.com -D "uid=lee,ou=people,dc=example,dc=com" -W -S -x -A slapd is compiled with "-g" option. One strange thing is that if slapd is compiled with "-ggdb", then the problem disappears. I am going to run some more tests with "-ggdb" to make sure that's the case. If you need further information, please let me know. Simon

1 0

Re: (ITS#5022) ldappasswd crash consumer slapd with some loglevels
by quanah＠zimbra.com 19 Jun '07

19 Jun '07

--On June 19, 2007 10:19:15 PM +0000 gao(a)schrodinger.com wrote: > Program received signal SIGABRT, Aborted. > [Switching to Thread -1249219696 (LWP 7710)] > 0xbfffe402 in __kernel_vsyscall () > (gdb) bt full ># 0 0xbfffe402 in __kernel_vsyscall () > No symbol table info available. ># 1 0xb7a8d429 in raise () from /lib/libc.so.6 > No symbol table info available. ># 2 0xb7a8e9d1 in abort () from /lib/libc.so.6 > No symbol table info available. ># 3 0xb7a86e51 in __assert_fail () from /lib/libc.so.6 > No symbol table info available. ># 4 0x080809c5 in send_ldap_response () > No symbol table info available. ># 5 0x0000000a in ?? () > No symbol table info available. ># 6 0x08150731 in ?? () > No symbol table info available. ># 7 0x08150731 in ?? () > No symbol table info available. ># 8 0xb58a61b4 in ?? () > No symbol table info available. ># 9 0xb58a5cac in ?? () > No symbol table info available. ># 10 0x00000000 in ?? () > No symbol table info available. Fairly worthless. You need to compile with -g and not strip the binary. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

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

19 Jun '07

Pierangelo Masarati wrote: > >> I would expect writing less log should help avoiding problem. In this >> case, somehow logging must be set at certain or above a level. Below >> that it will trigger problem. While I was trying to get pieces working, >> I always set loglevel to 1 or -1. So I did not realize this problem >> until very late. The error I got as a result of attempting change >> password is "can't contact LDAP server" which is very confusing (might >> be because slapd already crashed before serving last request). >> >> I am happy to run more tests and provide further information as needed. >> > > If slapd crashes, the only really useful info is a core dump, as > indicated in the FAQ I already pointed you to (that's basically why I > pointed you there: there's no point in always repeating instructions for > bug tracing, that's what the FAQ is intended for; apparently, it's > totally ignored). > > Adding one more information, the loglevel is 256 when the slapd crashed. Command used: ldappasswd -v -H ldap://ldap2.example.com -D "uid=user,ou=people,dc=example,dc=com" -W -S -x -A Coredump: ===================================================================== # gdb /tmp/debug/usr/lib/openldap/slapd GNU gdb 6.6 Copyright (C) 2006 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i686-pc-linux-gnu"... Using host libthread_db library "/lib/libthread_db.so.1". (gdb) run -d 0 -u ldap -g ldap -h 'ldap:// ldaps://' Starting program: /tmp/debug/usr/lib/openldap/slapd -d 0 -u ldap -g ldap -h 'ldap:// ldaps://' [Thread debugging using libthread_db enabled] [New Thread -1213843792 (LWP 7706)] [New Thread -1240826992 (LWP 7709)] [New Thread -1249219696 (LWP 7710)] [New Thread -1257612400 (LWP 7711)] slapd: result.c:364: send_ldap_response: Assertion `rs->sr_err != 0x0a' failed. Program received signal SIGABRT, Aborted. [Switching to Thread -1249219696 (LWP 7710)] 0xbfffe402 in __kernel_vsyscall () (gdb) bt full #0 0xbfffe402 in __kernel_vsyscall () No symbol table info available. #1 0xb7a8d429 in raise () from /lib/libc.so.6 No symbol table info available. #2 0xb7a8e9d1 in abort () from /lib/libc.so.6 No symbol table info available. #3 0xb7a86e51 in __assert_fail () from /lib/libc.so.6 No symbol table info available. #4 0x080809c5 in send_ldap_response () No symbol table info available. #5 0x0000000a in ?? () No symbol table info available. #6 0x08150731 in ?? () No symbol table info available. #7 0x08150731 in ?? () No symbol table info available. #8 0xb58a61b4 in ?? () No symbol table info available. #9 0xb58a5cac in ?? () No symbol table info available. #10 0x00000000 in ?? () No symbol table info available. =================================================================== Simon

1 0

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

19 Jun '07

Pierangelo Masarati wrote: >> Sorry about the broken link. Here is the correct one: >> >> ftp://ftp.schrodinger.com/support/openldap/simon.gao.openldap_20070618.ext >> >> >>>> When following command against a consumer slapd, it will crash slapd of the >>>> consumer when loglevel is set to any other value other than 1 or -1 on the >>>> consumer: >>>> >>>> ldappasswd -v -H ldap://consumer -D "uid=joe,ou=people,dc=example,dc=com" -W -S >>>> -x -A >>>> >>>> The crash happens to at least to loglevel 0, 256, 512. When loglevel is set to 1 >>>> or "-1", then no crash is experienced. In addition, when run consumer slapd >>>> manually as front process, >>>> >>>> >>> ^^^ what does this mean? >>> >>> >> If I start slapd manually as following commands: >> >> /usr/lib/openldap/slapd -d 0 -u ldap -g ldap -h 'ldap:// ldaps' >> /usr/lib/openldap/slapd -d 256 -u ldap -g ldap -h 'ldap:// ldaps' >> /usr/lib/openldap/slapd -d 512 -u ldap -g ldap -h 'ldap:// ldaps' >> >> Then I did not see the problem as I would when setting loglevel to 0, >> 256, 512 in slapd.conf and start slapd from /etc/init.d/slapd, which >> launch the daemon with the same options. When starting slapd from >> /etc/init.d/slapd as background daemon process, slapd will write to >> /var/log/ldap.log and /var/log/message. It seems that the difference >> exists between writing ldap logs to a file (slapd runs in background) or >> writing to console (slapd runs in foreground as started manually). >> >> >>> >>> >>>> then all debug level works without problem. >>>> >>>> >>> OpenLDAP re23 (in practice, 2.3.36 just released) doesn't show anything >>> like that. I note that differences related to the debug level usually >>> mean that a NULL or an invalid pointer is passed to a *printf(3) routine >>> on those systems that do not tolerate it (e.g. Solaris). But usually >>> the bug disappears when __decreasing__ the log level, while -1 means all. >>> >>> p. >>> >>> >> I would expect writing less log should help avoiding problem. In this >> case, somehow logging must be set at certain or above a level. Below >> that it will trigger problem. While I was trying to get pieces working, >> I always set loglevel to 1 or -1. So I did not realize this problem >> until very late. The error I got as a result of attempting change >> password is "can't contact LDAP server" which is very confusing (might >> be because slapd already crashed before serving last request). >> >> I am happy to run more tests and provide further information as needed. >> > > If slapd crashes, the only really useful info is a core dump, as > indicated in the FAQ I already pointed you to (that's basically why I > pointed you there: there's no point in always repeating instructions for > bug tracing, that's what the FAQ is intended for; apparently, it's > totally ignored). > > Not entirely. I thought system environment information might be useful too. Anyway. Here is the coredump. Let me know if this is enough. ==================================================================== # gdb /tmp/debug/usr/lib/openldap/slapd GNU gdb 6.6 Copyright (C) 2006 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i686-pc-linux-gnu"... Using host libthread_db library "/lib/libthread_db.so.1". (gdb) run -d 0 -u ldap -g ldap -h 'ldap:// ldaps://' Starting program: /tmp/debug/usr/lib/openldap/slapd -d 0 -u ldap -g ldap -h 'ldap:// ldaps://' [Thread debugging using libthread_db enabled] [New Thread -1213843792 (LWP 7706)] [New Thread -1240826992 (LWP 7709)] [New Thread -1249219696 (LWP 7710)] [New Thread -1257612400 (LWP 7711)] slapd: result.c:364: send_ldap_response: Assertion `rs->sr_err != 0x0a' failed. Program received signal SIGABRT, Aborted. [Switching to Thread -1249219696 (LWP 7710)] 0xbfffe402 in __kernel_vsyscall () (gdb) bt full #0 0xbfffe402 in __kernel_vsyscall () No symbol table info available. #1 0xb7a8d429 in raise () from /lib/libc.so.6 No symbol table info available. #2 0xb7a8e9d1 in abort () from /lib/libc.so.6 No symbol table info available. #3 0xb7a86e51 in __assert_fail () from /lib/libc.so.6 No symbol table info available. #4 0x080809c5 in send_ldap_response () No symbol table info available. #5 0x0000000a in ?? () No symbol table info available. #6 0x08150731 in ?? () No symbol table info available. #7 0x08150731 in ?? () No symbol table info available. #8 0xb58a61b4 in ?? () No symbol table info available. #9 0xb58a5cac in ?? () No symbol table info available. #10 0x00000000 in ?? () No symbol table info available. ===================================================================== Simon

1 0

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

19 Jun '07

hyc(a)symas.com writes: >h.b.furuseth(a)usit.uio.no wrote: >> Eh? Yes, that's what I was talking about. But I'm not sure what you >> mean with them exiting immediately - or how they could. Also they stay >> around until there are no pending requests. A pause request could >> arrive more or less at any time, I presume. (I don't know if there is a >> pause while the max threads number is being modified.) > > Yes. As stated back in the distant past, cn=config fully serializes > all write operations. The pool is paused for each write op. Oh, right. > When the op completes and the pool is resumed, the condition variable > is broadcasted, so all the other threads will wake up, and the first > to do so will see that they're above the max and exit, before any > other tasks are started. No, they won't exit pool_wrapper() while there are pending requests, but if that is a bug it is easy to fix. And by that description the wait I inserted after context_reset() in pool_wrapper() should not be there, since it releases ltp_mutex before the ID is removed from thread_keys[]. However another thread could be waiting in pool_pause() and start another pause. And the thread which did pool_resume() will be active and could call pool_pause() again (but I think it won't in the same LDAP operation with the current bconfig.c code). So if pool_wrapper() does not go active for context_reset() we must ensure that a pause is not started while a thread in pool_wrapper() is dying. That leaves thread_keys[] protected by either a pause or one of two mutexes, depending on circumstances. I'll sleep on it before trying to wrap my head around that one:-) >> (...) We did have code which compared thread IDs with '==' for >> quite some time. Do you remember if anyone complained, or if the >> switch to using ldap_pvt_thread_equal() was a "just in case" fix? > > Yes, I needed to use pthread_equal() on OS/390 since their thread type > was a structure. Ouch. That kills my tls.c patch too. I so hoped not to hear of an example... >> BTW I don't know if the unsigned long needs to be the thread ID or just >> _some_ unique integer. A question to openssl-users(a)openssl.org got no >> answer. > > It just needs to be a unique integer. I've already had this > conversation with the OpenSSL folks... Got a reference to that which I can beat them with? (To get them to update their doc if nothing else.) >>>>>>> The best fix may be to just use the address of the thread's >>>>>>> stack as the thread ID. That's actually perfect for our purpose. >> (...) >> Hmm. I asked the wrong question, should have read some man pages first. >> Still, thr_cthreads.c & thr_lwp.c don't use LDAP_PVT_THREAD_STACK_SIZE. >> man pthread_attr_getstacksize says it sets the _minimum_ stack size, but >> perhaps several M is large enough that one can expect it won't get >> multiples of that. > > That kinda implies that no one has been using the cthreads or lwp support > recently, since I doubt their default stack size would work with back-bdb's > filterindex demands. Um, okay... could remove them from configure and tell anyone who needs them to shout. How about pool_context() called from subsystems which create their own threads (like Perl code or plugins)? I guess it's just that I don't see I why using a private, hopefully-OS-independent hack is an improvement over OS-provided thread-specific data (when that is supported). Any risk that there are systems around which support non-contiguous stacks? (Allocate a new stack chunk if the current one is used up, and chain it to the old one.) I don't have a clue how common they are or were, nor of the arguments for/against implementing them. -- Regards, Hallvard

1 0

Re: (ITS#4943) tpool.c pause vs. finish
by hyc＠symas.com 19 Jun '07

19 Jun '07

h.b.furuseth(a)usit.uio.no wrote: > hyc(a)symas.com writes: >> h.b.furuseth(a)usit.uio.no wrote: >>> It's called from pool_wrapper(). pool_wrapper() could go active so >>> there can be no pause while that context_reset() call is running. >> Oh, ok. This is pretty much a non-issue because threads in the pool stay >> live until slapd shuts down. The one exception is for a cn=config modify >> that decreases the size of the pool to below the number of currently >> active threads, in which case some number of threads will exit >> immediately. I don't see any potential for conflict here. > > Eh? Yes, that's what I was talking about. But I'm not sure what you > mean with them exiting immediately - or how they could. Also they stay > around until there are no pending requests. A pause request could > arrive more or less at any time, I presume. (I don't know if there is a > pause while the max threads number is being modified.) Yes. As stated back in the distant past, cn=config fully serializes all write operations. The pool is paused for each write op. When the op completes and the pool is resumed, the condition variable is broadcasted, so all the other threads will wake up, and the first to do so will see that they're above the max and exit, before any other tasks are started. >> Casting to an int only works with simple types, the point of using the >> hash was to provide a solution that works for both simple and structured >> thread IDs. > > Yes, except it's not guaranteed to work. Which is why I'm thinking it > may be better to fail to compile and provide a fix if/when someone > complains. We did have code which compared thread IDs with '==' for > quite some time. Do you remember if anyone complained, or if the > switch to using ldap_pvt_thread_equal() was a "just in case" fix? Yes, I needed to use pthread_equal() on OS/390 since their thread type was a structure. > However note that we do > #define ldap_int_thread_equal(a, b) ((a) == (b)) > for all our supported thread implementations except pthreads, and > for pthreads we can test pthread_<set/get>specific() just fine > (as a replacement for thread_keys[]). > > OTOH, '==' also works for pointers that are wider than any integer type > (and for floating-point thread IDs:-) so I guess I'm arguing against my > own suggestion on that one if we add pthread_<set/get>specific() > support. > >> If you want to #ifdef the code so the two cases are handled >> differently, then just get rid of TID_HASH for the integral case. > > No, sould still hash to avoid clustering. > >> I'm still leary of the pthread TLS support, > > Me too. But the old code was broken on real-life systems I have access > to, not just on theoretical ones. Still waiting to hear from Kurt if my > fix to the first tls.c change fixed it for FreeBSD. > >> and making that change will >> require us to update all of the other thread package support, some of >> which I don't have access to build/test any more (e.g. SunOS4 LWP). > > What do you mean? The TLS problem is to extract an unsigned long from a > ldap_pvt_thread_t. That needs no support in the thr_*.c files, only to > know what kind of type ldap_pvt_thread_t is. Once configure knows what > ldap_pvt_thread_t will be typedeffed to it can test if that's a pointer, > integer or something worse - and whether it's too wide for a long. > > BTW I don't know if the unsigned long needs to be the thread ID or just > _some_ unique integer. A question to openssl-users(a)openssl.org got no > answer. It just needs to be a unique integer. I've already had this conversation with the OpenSSL folks... >>>>>> The best fix may be to just use the address of the thread's stack as the >>>>>> thread ID. That's actually perfect for our purpose. >>> (...) >>> I'm not sure how to determine _which_ multiple of 1MB - start two >>> threads and compare their stack addresses, maybe? In any case, I >>> agree it sounds rather more machine-dependent than the current code. >> That's what the LDAP_PVT_THREAD_STACK_SIZE macro tells you. It's really >> not hard. If we were to disallow increasing the number of threads at >> runtime, we could simply allocate a block of thread stacks all at once, >> which would then allow our thread IDs to be simple integers from 0-N. > > Hmm. I asked the wrong question, should have read some man pages first. > Still, thr_cthreads.c & thr_lwp.c don't use LDAP_PVT_THREAD_STACK_SIZE. > man pthread_attr_getstacksize says it sets the _minimum_ stack size, but > perhaps several M is large enough that one can expect it won't get > multiples of that. That kinda implies that no one has been using the cthreads or lwp support recently, since I doubt their default stack size would work with back-bdb's filterindex demands. -- -- 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

(ITS#5025) back_ldap crashes if it gets a search reference from remote server
by mhardin＠symas.com 19 Jun '07

19 Jun '07

Full_Name: Matthew Hardin Version: 2.3.35 OS: Linux 2.6.9 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (63.193.240.128) The back_ldap backend crashes if it gets a search reference from the remote server. The following patch corrects the problem. --- search.c 2007-06-19 11:01:13.000000000 -0700 +++ search.c.patched 2007-06-19 10:50:38.000000000 -0700 @@ -383,6 +383,7 @@ BER_BVZERO( &rs->sr_ref[ cnt ] ); /* ignore return value by now */ + rs->sr_entry = NULL; ( void )send_search_reference( op, rs ); } else {

1 0

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

19 Jun '07

hyc(a)symas.com writes: >h.b.furuseth(a)usit.uio.no wrote: >> It's called from pool_wrapper(). pool_wrapper() could go active so >> there can be no pause while that context_reset() call is running. > > Oh, ok. This is pretty much a non-issue because threads in the pool stay > live until slapd shuts down. The one exception is for a cn=config modify > that decreases the size of the pool to below the number of currently > active threads, in which case some number of threads will exit > immediately. I don't see any potential for conflict here. Eh? Yes, that's what I was talking about. But I'm not sure what you mean with them exiting immediately - or how they could. Also they stay around until there are no pending requests. A pause request could arrive more or less at any time, I presume. (I don't know if there is a pause while the max threads number is being modified.) >>>>> How can a single thread ID be represented by multiple bit patterns? >>>> A struct/union with padding bytes seems the least unlikely possibility. >> (...) >> So in that respect, my preference (not for RE23) is to cast to an >> integer for the hash, and also to add pthread_<set/get>specific() so >> thread_keys[] and its hash will only be a fallback solution. > > Casting to an int only works with simple types, the point of using the > hash was to provide a solution that works for both simple and structured > thread IDs. Yes, except it's not guaranteed to work. Which is why I'm thinking it may be better to fail to compile and provide a fix if/when someone complains. We did have code which compared thread IDs with '==' for quite some time. Do you remember if anyone complained, or if the switch to using ldap_pvt_thread_equal() was a "just in case" fix? However note that we do #define ldap_int_thread_equal(a, b) ((a) == (b)) for all our supported thread implementations except pthreads, and for pthreads we can test pthread_<set/get>specific() just fine (as a replacement for thread_keys[]). OTOH, '==' also works for pointers that are wider than any integer type (and for floating-point thread IDs:-) so I guess I'm arguing against my own suggestion on that one if we add pthread_<set/get>specific() support. > If you want to #ifdef the code so the two cases are handled > differently, then just get rid of TID_HASH for the integral case. No, sould still hash to avoid clustering. > I'm still leary of the pthread TLS support, Me too. But the old code was broken on real-life systems I have access to, not just on theoretical ones. Still waiting to hear from Kurt if my fix to the first tls.c change fixed it for FreeBSD. > and making that change will > require us to update all of the other thread package support, some of > which I don't have access to build/test any more (e.g. SunOS4 LWP). What do you mean? The TLS problem is to extract an unsigned long from a ldap_pvt_thread_t. That needs no support in the thr_*.c files, only to know what kind of type ldap_pvt_thread_t is. Once configure knows what ldap_pvt_thread_t will be typedeffed to it can test if that's a pointer, integer or something worse - and whether it's too wide for a long. BTW I don't know if the unsigned long needs to be the thread ID or just _some_ unique integer. A question to openssl-users(a)openssl.org got no answer. >>>>> The best fix may be to just use the address of the thread's stack as the >>>>> thread ID. That's actually perfect for our purpose. >> (...) >> I'm not sure how to determine _which_ multiple of 1MB - start two >> threads and compare their stack addresses, maybe? In any case, I >> agree it sounds rather more machine-dependent than the current code. > > That's what the LDAP_PVT_THREAD_STACK_SIZE macro tells you. It's really > not hard. If we were to disallow increasing the number of threads at > runtime, we could simply allocate a block of thread stacks all at once, > which would then allow our thread IDs to be simple integers from 0-N. Hmm. I asked the wrong question, should have read some man pages first. Still, thr_cthreads.c & thr_lwp.c don't use LDAP_PVT_THREAD_STACK_SIZE. man pthread_attr_getstacksize says it sets the _minimum_ stack size, but perhaps several M is large enough that one can expect it won't get multiples of that. -- Regards, Hallvard

1 0

Re: (ITS#5010) broken ber_encode_oid/ber_decode_oid()
by hyc＠symas.com 19 Jun '07

19 Jun '07

h.b.furuseth(a)usit.uio.no wrote: > I wrote: >> Finally, libldap/tls.c does not check if ber_decode_oid() fails. > > Fixed that. Waiting for the other stuff, depends on the code's intent. > Go ahead and fix whatever problems you see. Assume that maliciously constructed cert DNs are present, because undoubtedly there will be. -- -- 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#5005) test017 fails
by hyc＠symas.com 19 Jun '07

19 Jun '07

ando(a)sys-net.it wrote: > dieter(a)dkluenter.de wrote: > >> the patch fails, this is the patch reject file: > > That's probably because you cut'n'pasted from the email, where the tabs > were probably replaced by whitespaces. I'll apply that fix if anyone > confirms that cookie is legal at all. Yes. There's no hard definition of the cookie requirements. "rid=xxx" without a CSN is the same as no cookie at all. The patch seems to work here, go ahead and commit it. -- -- 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#5022) ldappasswd crash consumer slapd with some loglevels
by ando＠sys-net.it 19 Jun '07

19 Jun '07

Simon Gao wrote: > Pierangelo Masarati wrote: >> gao(a)schrodinger.com wrote: >> >> >>> URL: ftp://ftp.schrodinger.com/support/openldap/simon.gao.openldap_2.3.35.its.ext >>> >> ^^^ This link is unreachable >> >> > Sorry about the broken link. Here is the correct one: > > ftp://ftp.schrodinger.com/support/openldap/simon.gao.openldap_20070618.ext > >>> When following command against a consumer slapd, it will crash slapd of the >>> consumer when loglevel is set to any other value other than 1 or -1 on the >>> consumer: >>> >>> ldappasswd -v -H ldap://consumer -D "uid=joe,ou=people,dc=example,dc=com" -W -S >>> -x -A >>> >>> The crash happens to at least to loglevel 0, 256, 512. When loglevel is set to 1 >>> or "-1", then no crash is experienced. In addition, when run consumer slapd >>> manually as front process, >>> >> ^^^ what does this mean? >> > If I start slapd manually as following commands: > > /usr/lib/openldap/slapd -d 0 -u ldap -g ldap -h 'ldap:// ldaps' > /usr/lib/openldap/slapd -d 256 -u ldap -g ldap -h 'ldap:// ldaps' > /usr/lib/openldap/slapd -d 512 -u ldap -g ldap -h 'ldap:// ldaps' > > Then I did not see the problem as I would when setting loglevel to 0, > 256, 512 in slapd.conf and start slapd from /etc/init.d/slapd, which > launch the daemon with the same options. When starting slapd from > /etc/init.d/slapd as background daemon process, slapd will write to > /var/log/ldap.log and /var/log/message. It seems that the difference > exists between writing ldap logs to a file (slapd runs in background) or > writing to console (slapd runs in foreground as started manually). > >> >>> then all debug level works without problem. >>> >> OpenLDAP re23 (in practice, 2.3.36 just released) doesn't show anything >> like that. I note that differences related to the debug level usually >> mean that a NULL or an invalid pointer is passed to a *printf(3) routine >> on those systems that do not tolerate it (e.g. Solaris). But usually >> the bug disappears when __decreasing__ the log level, while -1 means all. >> >> p. >> > > I would expect writing less log should help avoiding problem. In this > case, somehow logging must be set at certain or above a level. Below > that it will trigger problem. While I was trying to get pieces working, > I always set loglevel to 1 or -1. So I did not realize this problem > until very late. The error I got as a result of attempting change > password is "can't contact LDAP server" which is very confusing (might > be because slapd already crashed before serving last request). > > I am happy to run more tests and provide further information as needed. If slapd crashes, the only really useful info is a core dump, as indicated in the FAQ I already pointed you to (that's basically why I pointed you there: there's no point in always repeating instructions for bug tracing, that's what the FAQ is intended for; apparently, it's totally ignored). 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 19 Jun '07

19 Jun '07

Pierangelo Masarati wrote: > gao(a)schrodinger.com wrote: > > >> URL: ftp://ftp.schrodinger.com/support/openldap/simon.gao.openldap_2.3.35.its.ext >> > > ^^^ This link is unreachable > > Sorry about the broken link. Here is the correct one: ftp://ftp.schrodinger.com/support/openldap/simon.gao.openldap_20070618.ext >> When following command against a consumer slapd, it will crash slapd of the >> consumer when loglevel is set to any other value other than 1 or -1 on the >> consumer: >> >> ldappasswd -v -H ldap://consumer -D "uid=joe,ou=people,dc=example,dc=com" -W -S >> -x -A >> >> The crash happens to at least to loglevel 0, 256, 512. When loglevel is set to 1 >> or "-1", then no crash is experienced. In addition, when run consumer slapd >> manually as front process, >> > > ^^^ what does this mean? > If I start slapd manually as following commands: /usr/lib/openldap/slapd -d 0 -u ldap -g ldap -h 'ldap:// ldaps' /usr/lib/openldap/slapd -d 256 -u ldap -g ldap -h 'ldap:// ldaps' /usr/lib/openldap/slapd -d 512 -u ldap -g ldap -h 'ldap:// ldaps' Then I did not see the problem as I would when setting loglevel to 0, 256, 512 in slapd.conf and start slapd from /etc/init.d/slapd, which launch the daemon with the same options. When starting slapd from /etc/init.d/slapd as background daemon process, slapd will write to /var/log/ldap.log and /var/log/message. It seems that the difference exists between writing ldap logs to a file (slapd runs in background) or writing to console (slapd runs in foreground as started manually). > >> then all debug level works without problem. >> > > OpenLDAP re23 (in practice, 2.3.36 just released) doesn't show anything > like that. I note that differences related to the debug level usually > mean that a NULL or an invalid pointer is passed to a *printf(3) routine > on those systems that do not tolerate it (e.g. Solaris). But usually > the bug disappears when __decreasing__ the log level, while -1 means all. > > p. > I would expect writing less log should help avoiding problem. In this case, somehow logging must be set at certain or above a level. Below that it will trigger problem. While I was trying to get pieces working, I always set loglevel to 1 or -1. So I did not realize this problem until very late. The error I got as a result of attempting change password is "can't contact LDAP server" which is very confusing (might be because slapd already crashed before serving last request). I am happy to run more tests and provide further information as needed. Thanks, Simon

1 0

Re: (ITS#5022) ldappasswd crash consumer slapd with some loglevels
by quanah＠zimbra.com 18 Jun '07

18 Jun '07

--On Tuesday, June 19, 2007 5:37 AM +0000 ando(a)sys-net.it wrote: > gao(a)schrodinger.com wrote: > >> URL: >> ftp://ftp.schrodinger.com/support/openldap/simon.gao.openldap_2.3.35.its >> .ext <ftp://ftp.schrodinger.com/support/openldap/simon.gao.openldap_20070618.ext> is the actual file. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

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

18 Jun '07

gao(a)schrodinger.com wrote: > URL: ftp://ftp.schrodinger.com/support/openldap/simon.gao.openldap_2.3.35.its.ext ^^^ This link is unreachable > When following command against a consumer slapd, it will crash slapd of the > consumer when loglevel is set to any other value other than 1 or -1 on the > consumer: > > ldappasswd -v -H ldap://consumer -D "uid=joe,ou=people,dc=example,dc=com" -W -S > -x -A > > The crash happens to at least to loglevel 0, 256, 512. When loglevel is set to 1 > or "-1", then no crash is experienced. In addition, when run consumer slapd > manually as front process, ^^^ what does this mean? > then all debug level works without problem. OpenLDAP re23 (in practice, 2.3.36 just released) doesn't show anything like that. I note that differences related to the debug level usually mean that a NULL or an invalid pointer is passed to a *printf(3) routine on those systems that do not tolerate it (e.g. Solaris). But usually the bug disappears when __decreasing__ the log level, while -1 means all. p. 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#4986) manageDSAit might control cause problems in database selection
by hyc＠symas.com 18 Jun '07

18 Jun '07

hyc(a)symas.com wrote: > ando(a)sys-net.it wrote: >> A tentative fix is in HEAD (servers/slapd/backend.c 1.377 -> 1.378). >> >> Please test. > > Not entirely sure about that test myself. The original is rev 1.94 > > revision 1.94 > date: 2000/10/21 01:29:02; author: kurt; state: Exp; lines: +20 -7 > First-cut at manageDSAit-aware backend selection. > > Seems a bit unnecessary really. > Thinking back, I think the idea here is that you might have a set of nested databases connected by referral entries. E.g., database ldbm suffix dc=sub,dc=example,dc=com database ldbm suffix dc=example,dc=com If you had an referral entry in the superior DB that pointed to the sub database, you would need the manageDSAit control to be able to operate on the referral entry. None of this really makes sense post 2.1 since subordinate/glue makes it superfluous. -- -- 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#4986) manageDSAit might control cause problems in database selection
by hyc＠symas.com 18 Jun '07

18 Jun '07

ando(a)sys-net.it wrote: > A tentative fix is in HEAD (servers/slapd/backend.c 1.377 -> 1.378). > > Please test. Not entirely sure about that test myself. The original is rev 1.94 revision 1.94 date: 2000/10/21 01:29:02; author: kurt; state: Exp; lines: +20 -7 First-cut at manageDSAit-aware backend selection. Seems a bit unnecessary really. -- -- 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#5024) Disabling pagedResults advertisements
by hyc＠symas.com 18 Jun '07

18 Jun '07

v_orgos(a)yahoo.com.au wrote: > Full_Name: Vic Orgos > Version: 2.2.13 > OS: RHEL4 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (61.9.136.163) > I really do not want to have to maintain a custom RPM or have to patch RedHat's > everytime there is an update/security patch. 2.2.13 was obsoleted years ago. If you can't get adequate support from RedHat then you should upgrade to a current release. This ITS will be closed. -- -- 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

(ITS#5024) Disabling pagedResults advertisements
by v_orgos＠yahoo.com.au 18 Jun '07

18 Jun '07

Full_Name: Vic Orgos Version: 2.2.13 OS: RHEL4 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (61.9.136.163) Hi, I am upgrading from 2.0.xx (RHEL3) to 2.2.13 on RHEL4. Outlook 2003 clients have been using the old ldap server with no issues at all but during testing on the new RHEL4 test server I've come across the problem discussed at http://www.openldap.org/lists/openldap-software/200408/msg00298.html As suggested I've tried to stop it advertising pagedResults but it does not work. I've tried access to dn.exact="" filter="(supportedControl=1.2.840.113556.1.4.319)" by * none but this does not work and I've tried ccess to dn.exact="" attrs=supportedControl val=1.2.840.113556.1.4.319 by * none which seg faults. I would appreciate if you would provide me with the correct syntax or some means to allow Outlook to work correctly. I really do not want to have to maintain a custom RPM or have to patch RedHat's everytime there is an update/security patch. Thank you for your time. Vic.

1 0

(ITS#5023) ldappasswd crash consumer slapd with some loglevels
by gao＠schrodinger.com 18 Jun '07

18 Jun '07

Full_Name: Simon Gao Version: 2.3.35 OS: Gentoo Linux 2007.0 kernel 2.6.16 URL: ftp://ftp.schrodinger.com/support/openldap/simon.gao.openldap_20070618.ext Submission from: (NULL) (192.156.98.12) When following command against a consumer slapd, it will crash slapd of the consumer when loglevel is set to any other value other than 1 or -1 on the consumer: ldappasswd -v -H ldap://consumer -D "uid=joe,ou=people,dc=example,dc=com" -W -S -x -A The crash happens to at least to loglevel 0, 256, 512. When loglevel is set to 1 or "-1", then no crash is experienced. In addition, when run consumer slapd manually as front process, then all debug level works without problem. Please check attached ftp link for detailed logs and information.

1 0

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

18 Jun '07

Full_Name: Simon Gao Version: 2.3.35 OS: Gentoo Linux 2007.0 kernel 2.6.16 URL: ftp://ftp.schrodinger.com/support/openldap/simon.gao.openldap_2.3.35.its.ext Submission from: (NULL) (192.156.98.12) When following command against a consumer slapd, it will crash slapd of the consumer when loglevel is set to any other value other than 1 or -1 on the consumer: ldappasswd -v -H ldap://consumer -D "uid=joe,ou=people,dc=example,dc=com" -W -S -x -A The crash happens to at least to loglevel 0, 256, 512. When loglevel is set to 1 or "-1", then no crash is experienced. In addition, when run consumer slapd manually as front process, then all debug level works without problem. Please check attached ftp link for detailed logs and information.

1 0

Re: (ITS#4995) SampleLDAP.pm w/back_perl appears to be broken
by h.b.furuseth＠usit.uio.no 18 Jun '07

18 Jun '07

We've clarified the usage text in SampleLDAP.py. -- Hallvard

1 0

Re: (ITS#5021) test021-certificate fails on HP-UX
by h.b.furuseth＠usit.uio.no 17 Jun '07

17 Jun '07

Howard Chu writes: > Are you using the same version of OpenSSL on your other test machines? > Have you tried a newer version? Yes, and not yet. > (...) But at the moment this seems to be an OpenSSL problem, in which > case we can close this ITS. Yes, or put it on Feedback. I'll have a closer look at this eventually, but just compiling OpenSSL on that HP box takes ages. Don't hold RE23 for this. -- Regards, Hallvard

1 0

Re: (ITS#5021) test021-certificate fails on HP-UX
by hyc＠symas.com 16 Jun '07

16 Jun '07

h.b.furuseth(a)usit.uio.no wrote: > Bug in OpenSSL 0.9.7d - unless it's with how OpenLDAP uses it, I don't > know. Are you using the same version of OpenSSL on your other test machines? Have you tried a newer version? Makes sense that this wouldn't be a problem in HEAD since we're now using liblber for certificate handling. I suppose we could patch RE23 to use ber_get_int for the serial number. But at the moment this seems to be an OpenSSL problem, in which case we can close this ITS. > The offending operation (on Jennifer Smith) adds one certificate and > deletes the old one. However the added and the old certificate compare > equal because certificateExactNormalize() produces the same string for > both: > 0$email=ca(a)example.com,cn=example ca, > o=openldap example\2C ltd.,st=california,c=us > > That's because i2s_ASN1_INTEGER(0, sn ) in certificateExactNormalize() > returns serial number "0". The inputs to that function are > (gdb) p *sn > $6 = {length = 1, type = 2, data = 0x402e5278 "\003", flags = 0} > and > (gdb) p *sn > $8 = {length = 1, type = 2, data = 0x402e5cf0 "\001xample.@\036", flags = 0} > Those *sn values are the same as on a successful run on Linux, except > the 2nd data[1...] (the xample... string) which I presume does not > matter when length=1. > > The input certificates ('val' arg to certificateExactNormalize()) are > correct. > -- -- 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#5021) test021-certificate fails on HP-UX
by h.b.furuseth＠usit.uio.no 16 Jun '07

16 Jun '07

Bug in OpenSSL 0.9.7d - unless it's with how OpenLDAP uses it, I don't know. The offending operation (on Jennifer Smith) adds one certificate and deletes the old one. However the added and the old certificate compare equal because certificateExactNormalize() produces the same string for both: 0$email=ca(a)example.com,cn=example ca, o=openldap example\2C ltd.,st=california,c=us That's because i2s_ASN1_INTEGER(0, sn ) in certificateExactNormalize() returns serial number "0". The inputs to that function are (gdb) p *sn $6 = {length = 1, type = 2, data = 0x402e5278 "\003", flags = 0} and (gdb) p *sn $8 = {length = 1, type = 2, data = 0x402e5cf0 "\001xample.@\036", flags = 0} Those *sn values are the same as on a successful run on Linux, except the 2nd data[1...] (the xample... string) which I presume does not matter when length=1. The input certificates ('val' arg to certificateExactNormalize()) are correct. -- Regards, Hallvard

1 0

Re: (ITS#5021) test021-certificate fails on HP-UX
by h.b.furuseth＠usit.uio.no 16 Jun '07

16 Jun '07

quanah(a)zimbra.com writes: > conn=1 op=4 MOD attr=userCertificate;binary userCertificate;binary > Why is it modifying the same attribute twice? It adds one cert and deletes another in the same op. The log from a successful run on Linux shows the same. -- Regards, Hallvard

1 0

Re: (ITS#5021) test021-certificate fails on HP-UX
by quanah＠zimbra.com 15 Jun '07

15 Jun '07

--On June 15, 2007 9:59:56 PM +0000 h.b.furuseth(a)usit.uio.no wrote: > Full_Name: Hallvard B Furuseth > Version: RE23, 2.3.35 > OS: HP-UX > URL: ftp://ftp.openldap.org/incoming/Hallvard-Furuseth-070615.tgz > Submission from: (NULL) (129.240.202.105) > Submitted by: hallvard > > > test021-certificate fails on HP-UX in RE23 and 2.3.35. It succeeds in > HEAD. > > OpenSSL version: 0.9.7d. > > I enclose the testrun directory from: > > $ ./run -b ldif test021-certificate > Cleaning up test run directory leftover from previous run. > Running ./scripts/test021-certificate... > running defines.sh > Running slapadd to build slapd database... > Starting slapd on TCP/IP port 9011... > Testing certificate handling... > Add certificates... > ldapmodify failed (20)! > The last modify is erroring with already exists. The last logged modify looks really weird to me: conn=1 op=4 MOD attr=userCertificate;binary userCertificate;binary Why is it modifying the same attribute twice? --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#5021) test021-certificate fails on HP-UX
by h.b.furuseth＠usit.uio.no 15 Jun '07

15 Jun '07

Full_Name: Hallvard B Furuseth Version: RE23, 2.3.35 OS: HP-UX URL: ftp://ftp.openldap.org/incoming/Hallvard-Furuseth-070615.tgz Submission from: (NULL) (129.240.202.105) Submitted by: hallvard test021-certificate fails on HP-UX in RE23 and 2.3.35. It succeeds in HEAD. OpenSSL version: 0.9.7d. I enclose the testrun directory from: $ ./run -b ldif test021-certificate Cleaning up test run directory leftover from previous run. Running ./scripts/test021-certificate... running defines.sh Running slapadd to build slapd database... Starting slapd on TCP/IP port 9011... Testing certificate handling... Add certificates... ldapmodify failed (20)!

1 0

Re: (ITS#5020) configure needs -pthread to find pthread.h
by h.b.furuseth＠usit.uio.no 15 Jun '07

15 Jun '07

I wrote: > ./configure CC="cc -pthread" works. Well, it configures. Then it fails to build shared libraries because libtool invokes ld ... -pthread, and ld does not accept -pthread. But I guess that should be reported to the libtool folks. ./configure --disable-shared CC="cc -pthread" does work. -- Regards, Hallvard

1 0

Re: (ITS#5014) syncrepl failure syslog
by donn＠u.washington.edu 15 Jun '07

15 Jun '07

On Jun 14, 2007, at 2:08 PM, Pierangelo Masarati wrote: > So what's really relevant in your patch, and > missing from the code, is a test for "err" after the "done" label. I > have applied something along those lines to the code. Please test. Yes, this works in my case - if indeed the test is after "done:". You accidentally put it before, and it doesn't work there. Thanks! Donn Cave, donn(a)u.washington.edu

1 0

(ITS#5020) configure needs -pthread to find pthread.h
by h.b.furuseth＠usit.uio.no 15 Jun '07

15 Jun '07

Full_Name: Hallvard B Furuseth Version: HEAD, RE23 OS: OSF1 V5.1 alpha URL: Submission from: (NULL) (129.240.202.105) Submitted by: hallvard /configure on OSF1 alpha finds no suitable threading library. config.log says: configure:19993: checking pthread.h usability configure:20005: cc -c -g -I/local/include -I/local/gnu/include conftest.c >&5 cc: Error: /usr/include/pthread.h, line 1251: #error "Please compile the module including pthread.h with -pthread" (errormessage) due to this snippet of pthread.h: # ifndef _REENTRANT # error "Please compile the module including pthread.h with -pthread" # endif ./configure CC="cc -pthread" works. Not sure how to deal with that one. Seems a bit excessive to run all the OL_PTHREAD_TRY()s _before_ detecting that the system has pthread. Maybe write a special case, like try for pthread.h with -D_REENTRANT if not found without that?

1 0

Re: (ITS#5016) slapd generates unjustified error 3 (Time Limit Exceeded) at checkpoint time
by ali.pouya＠free.fr 15 Jun '07

15 Jun '07

pierangelo.masarati(a)sys-net.it wrote : > Would it be possible to get, from the consumer's log, what was the > actually requested time limit in those cases? This means: track down > what connection/operation was concluded by a "Time Limit Exceeded" > response; then find out the corresponding request, and see what was the > requested time limit. You need "args" debug level for this purpose, and > you need to look at the second of the three numbers that end the SRCH > line in the logs; for example: Hi Pierangelo; The problem came from my LDAP client which specified timelimit=1. I repaired the client and everything works fine since several hours :-) Thanks for your help and sorry for wasting your time. For me the ITS is to be closed (the error "Time Limit Exceeded" produced for syncrepl connection every 3600 seconds does not bother me). Best regards Ali

1 0

Re: memory leak (ITS#5018)
by niloulili＠hotmail.com 14 Jun '07

14 Jun '07

OK,I've download release 2.3.32,after removing and test ,i'll report whether problem still exits. Thank you so much. best regards nina >From: Pierangelo Masarati <openldap-its(a)OpenLDAP.org> >To: niloulili(a)hotmail.com >Subject: Re: memory leak (ITS#5018) >Date: Thu, 14 Jun 2007 08:13:11 GMT > >OpenLDAP 2.2.19 (and OpenLDAP 2.2) has been abandoned long ago, so it is no >longer maintained. Please upgrade to a recent version and check if the problem >persists. Otherwise this ITS will be closed. > >p. _________________________________________________________________ ÓëÁª»úµÄÅóÓÑœøÐÐœ»Á÷£¬ÇëÊ¹ÓÃ MSN Messenger: http://messenger.msn.com/cn

1 0

Re: (ITS#4995) SampleLDAP.pm w/back_perl appears to be broken
by rra＠stanford.edu 14 Jun '07

14 Jun '07

Quanah Gibson-Mount <quanah(a)zimbra.com> writes: > --On Saturday, June 02, 2007 4:43 AM +0000 rra(a)stanford.edu wrote: >> While investigating another issue with back_perl, I tried to use the >> SampleLDAP.pm module that comes with the OpenLDAP source. I added the >> following to my slapd.conf: >> database perl >> suffix "o=AnyOrg,c=US" >> perlModulePath /home/eagle/SampleLDAP.pm >> perlModule SampleLDAP [...] > database perl > suffix "o=AnyOrg,c=US" > perlModulePath /usr/local/etc/openldap > perlModule SampleLDAP I detect an intriguing difference in our configurations. I was misled by this comment in SampleLDAP.pm: # Usage: Add something like this to slapd.conf: # # database perl # suffix "o=AnyOrg,c=US" # perlModulePath /path/to/this/file # perlModule SampleLDAP The man page is more accurate. This was apparently actually a minor bug in the comments. :) -- Russ Allbery (rra(a)stanford.edu) <http://www.eyrie.org/~eagle/>

1 0

Re: (ITS#4995) SampleLDAP.pm w/back_perl appears to be broken
by quanah＠zimbra.com 14 Jun '07

14 Jun '07

--On Saturday, June 02, 2007 4:43 AM +0000 rra(a)stanford.edu wrote: > Full_Name: Russ Allbery > Version: 2.3.35 > OS: Debian > URL: > Submission from: (NULL) (171.66.157.14) > > > While investigating another issue with back_perl, I tried to use the > SampleLDAP.pm module that comes with the OpenLDAP source. I added the > following to my slapd.conf: > > moduleload back_perl > ># ... > > database perl > suffix "o=AnyOrg,c=US" > perlModulePath /home/eagle/SampleLDAP.pm > perlModule SampleLDAP > > The result of slapd -d 1 is: > ... > WARNING: No dynamic config support for database perl. > config_build_entry: "olcDatabase={2}perl" > backend_startup_one: starting "dc=Stanford,dc=EDU" > bdb_db_open: unclean shutdown detected; attempting recovery. > bdb_db_open: dbenv_open(/var/lib/ldap) > backend_startup_one: starting "o=AnyOrg,c=US" > Can't call method "init" on an undefined value. Using the SampleLDAP perl module supplied with the OpenLDAP source works just fine for me on Stanford's LDAP servers. ldap-uat00:/usr/local/etc/openldap# more slapd.conf # # See slapd.conf(5) for details on configuration options. # This file should NOT be world readable. # include /usr/local/etc/openldap/schema/core.schema include /usr/local/etc/openldap/schema/cosine.schema include /usr/local/etc/openldap/schema/inetorgperson.schema loglevel 0 threads 8 password-hash {CLEARTEXT} # Define global ACLs to disable default read access. pidfile /var/run/slapd.pid argsfile /var/run/slapd.args # # Load dynamic backend modules: # Note: back-null is statically-linked. modulepath /usr/local/lib/openldap moduleload back_perl.la access to dn="" by * read access to * by anonymous read by users read by self write # if no access controls are present, the default policy is: # Allow read by all # # rootdn can always write! tool-threads 2 ####################################################################### # perl database definitions ####################################################################### database perl suffix "o=AnyOrg,c=US" perlModulePath /usr/local/etc/openldap perlModule SampleLDAP Output from slapd -d -1 slapd startup: initiated. backend_startup_one: starting "cn=config" config_back_db_open config_build_entry: "cn=config" config_build_entry: "cn=include{0}" config_build_entry: "cn=include{1}" config_build_entry: "cn=include{2}" config_build_entry: "cn=module{0}" config_build_entry: "cn=schema" config_build_entry: "cn={0}core" config_build_entry: "cn={1}cosine" config_build_entry: "cn={2}inetorgperson" config_build_entry: "olcDatabase={-1}frontend" config_build_entry: "olcDatabase={0}config" WARNING: No dynamic config support for database perl. config_build_entry: "olcDatabase={1}perl" backend_startup_one: starting "o=AnyOrg,c=US" slapd starting daemon: added 4r listener=(nil) daemon: added 7r listener=0x6010e0 daemon: epoll: listen=7 active_threads=0 tvp=NULL daemon: activity on 1 descriptor daemon: activity on: daemon: epoll: listen=7 active_threads=0 tvp=NULL So I am unable to reproduce this issue. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#4943) tpool.c pause vs. finish
by hyc＠symas.com 14 Jun '07

14 Jun '07

h.b.furuseth(a)usit.uio.no wrote: > Howard Chu writes: >> Hallvard B Furuseth wrote: >>> hyc(a)symas.com writes: >>>> h.b.furuseth(a)usit.uio.no wrote: >>>>> * When a thread is finishing, make it go active for context_reset(). >>>>> Should make slapi module destructors safer, and I don't see that it >>>>> can hurt. >>>> I don't understand this. >>> Let me dig a bit back in the ITS... >>> "context_reset() can call connection_fake_destroy(), which via >>> slapi_int_free_object_extensions() calls slapi module destructors, >>> which can do who-knows-what." >> context_reset() can only be called from the main thread. It can (must) >> never be called by anything running from the pool. > > It's called from pool_wrapper(). pool_wrapper() could go active so > there can be no pause while that context_reset() call is running. Oh, ok. This is pretty much a non-issue because threads in the pool stay live until slapd shuts down. The one exception is for a cn=config modify that decreases the size of the pool to below the number of currently active threads, in which case some number of threads will exit immediately. I don't see any potential for conflict here. >>>>> * Scheduling: If several threads call pool_pause(), (...) > > (need to check out how it should work...) > >>>>> - pool_context() breaks if several ldap_pvt_thread_t bit patterns can >>>>> represent the same thread ID: TID_HASH() would give different hashes >>>>> for the same thread, and pool_context() stops searching when it hits >>>>> a slot with ctx == NULL. (My previous bug report was a bit wrong.) >>>> How can a single thread ID be represented by multiple bit patterns? >>> A struct/union with padding bytes seems the least unlikely possibility. > > Note that I did say "least unlikely" rather than "most likely": > It's not that I expect to encounter it, more that I'd prefer not to be > surprised in the form of a slapd malfuntion. > > So in that respect, my preference (not for RE23) is to cast to an > integer for the hash, and also to add pthread_<set/get>specific() so > thread_keys[] and its hash will only be a fallback solution. Casting to an int only works with simple types, the point of using the hash was to provide a solution that works for both simple and structured thread IDs. If you want to #ifdef the code so the two cases are handled differently, then just get rid of TID_HASH for the integral case. I'm still leary of the pthread TLS support, and making that change will require us to update all of the other thread package support, some of which I don't have access to build/test any more (e.g. SunOS4 LWP). >>>> The best fix may be to just use the address of the thread's stack as the >>>> thread ID. That's actually perfect for our purpose. >>> How does a function called from somewhere inside the thread know that >>> address? That's almost what the user context is, and thus what >>> thread_keys[] maps the thread ID to. >> It requires some degree of machine-dependence, which is why I never >> bothered to code it. The principle is simple though - all of our thread >> stacks are some multiple of 1MB in size. Take the address of any local >> variable, mask off the low 20 bits, and you have a unique thread ID (+/- >> some additional masking/shifting based on the actual thread stack size). > > I'm not sure how to determine _which_ multiple of 1MB - start two > threads and compare their stack addresses, maybe? In any case, I > agree it sounds rather more machine-dependent than the current code. That's what the LDAP_PVT_THREAD_STACK_SIZE macro tells you. It's really not hard. If we were to disallow increasing the number of threads at runtime, we could simply allocate a block of thread stacks all at once, which would then allow our thread IDs to be simple integers from 0-N. -- -- 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#5019) slapd: ldbm/gdbm, cache.c core dump
by quanah＠zimbra.com 14 Jun '07

14 Jun '07

--On Thursday, June 14, 2007 8:59 PM +0000 asedlack(a)mailfoundry.com wrote: > Full_Name: Aron Sedlack > Version: 2.3.35 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (66.18.18.14) > LDBM is deprecated, and has been removed from the source tree. Bugs against LDBM will not be fixed, because of its inherent flaws. Upgrade your configuration to use one of the supported database mechanisms, back-bdb or back-hdb. :) --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#5019) slapd: ldbm/gdbm, cache.c core dump
by hyc＠symas.com 14 Jun '07

14 Jun '07

asedlack(a)mailfoundry.com wrote: > Full_Name: Aron Sedlack > Version: 2.3.35 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (66.18.18.14) > > > Platform: Linux, OpenLDAP-2.3.35 > Compiled with: ./configure --enable-dynamic --enable-wrappers --enable-bdb=no > --enable-hdb=no --enable-ldbm --enable-ldbm-api=gdbm --with-threads --with-tls > --with-threads=no > gcc version 3.3.4, gdbm 1.8.3, OpenSSL 0.9.8e > > slapd core dumps with a corrupted stack, SIGABRT. > slapd: cache.c:111: cache_return_entry_rw: Assertion `e->e_private != (( void > *)0)' failed.. > > Happens every time ldif is loaded... > $ ldapmodify -a -f ./mf.ldif -D "cn=Root,dc=mf" -w secret > adding new entry "dc=mf" > > adding new entry "dc=iana,dc=mf" > ldap_result: Can't contact LDAP server (-1) 1) ldbm is deprecated, don't use it. 2) if you insist on using it, get a debug stack trace for the abort 3) note that ldbm is still tested regularly in the 2.3 builds, and no one else has reported this occurrence, so there's probably something odd in your configuration. Providing your slapd.conf might help. But the ldbm code has been removed for 2.4; support for it is disappearing fast. -- -- 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#4837) SunLDAP to OpenLDAP migration problem
by quanah＠zimbra.com 14 Jun '07

14 Jun '07

--On Thursday, June 14, 2007 10:02 PM +0000 h.b.furuseth(a)usit.uio.no wrote: > Quanah Gibson-Mount writes: >> It should be as simple as changing: >> passwd.c:#define SALT_SIZE 4 >> to >> passwd.c:#define SALT_SIZE 8 > > I don't get this. I don't know ssha1, but... Right, see my follow-up. I had the wrong string in my data when I did a cut and paste. ;) It actually works as it should. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#4837) SunLDAP to OpenLDAP migration problem
by h.b.furuseth＠usit.uio.no 14 Jun '07

14 Jun '07

Quanah Gibson-Mount writes: > It should be as simple as changing: > passwd.c:#define SALT_SIZE 4 > to > passwd.c:#define SALT_SIZE 8 I don't get this. I don't know ssha1, but... That's for generating ssha1 hashes in hash_ssha1(), it is not used for decoding them in chk_ssha1() - which I assume is what he needs when moving _to_ OpenLDAP. chk_ssha1() looks independent of salt size - it base64-decodes the provided salt+hash and finds expects the salt to start at position LUTIL_SHA1_BYTES (from include/lutil_sha1.h) in that string. -- Regards, Hallvard

1 0

Re: (ITS#4837)
by quanah＠zimbra.com 14 Jun '07

14 Jun '07

--On Thursday, June 14, 2007 9:23 PM +0000 quanah(a)zimbra.com wrote: > Kurt, > > Zimbra has run into this issue in helping a customer who was running > SunDS migrate to OpenLDAP. It does not work at all, unfortunately. > Changing code to use an 8-bit salt does work. Never mind, the 8-bit salt works just fine. I had bad data in my cut & paste buffer last night when I tried this. Trying with the correct data works just fine. yeah! I'll mark this ITS as invalid, and note in the comments that 8-bit salted SSHA passwords work just fine. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#4936) default modulepath
by ando＠sys-net.it 14 Jun '07

14 Jun '07

ando(a)sys-net.it wrote: > Yes, I figured that out. I'll fix this later. Fixed; please test. 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#4837)
by quanah＠zimbra.com 14 Jun '07

14 Jun '07

Kurt, Zimbra has run into this issue in helping a customer who was running SunDS migrate to OpenLDAP. It does not work at all, unfortunately. Changing code to use an 8-bit salt does work. So, I'd be happy to fix this, but a general design question -- (a) Should this be implemented as a "ssha-salt" option in slapd.conf or (b) Should OpenLDAP try decrypting the password first as a 4-bit salt, and then try an 8-bit salt, then fail? (a) would be fairly portable across many salt settings, but AFAIK we've only hit 4 & 8 (b) would allow mixed salt values to be in userPassword, and I'd think that over time as people changed their passwords, it would allow the 8-bit salts to go away. Thoughts welcome. :) --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#5014) syncrepl failure syslog
by ando＠sys-net.it 14 Jun '07

14 Jun '07

donn(a)u.washington.edu wrote: > Hard to tell why syncrepl isn't working, if it discards error messages. This patch was not submitted according to the guidelines of usual contributions, which makes it hard to apply. In any case, it appears to be incorrect, since the response code should not be extracted that early, namely before getting the message type. AFAIK, only an LDAP_RES_SEARCH_RESULT could contain an error, and that value is already parsed out and stored in "err". What's missing is a log in case "err" indicates an error. So what's really relevant in your patch, and missing from the code, is a test for "err" after the "done" label. I have applied something along those lines to the code. Please test. 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

(ITS#5019) slapd: ldbm/gdbm, cache.c core dump
by asedlack＠mailfoundry.com 14 Jun '07

14 Jun '07

Full_Name: Aron Sedlack Version: 2.3.35 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (66.18.18.14) Platform: Linux, OpenLDAP-2.3.35 Compiled with: ./configure --enable-dynamic --enable-wrappers --enable-bdb=no --enable-hdb=no --enable-ldbm --enable-ldbm-api=gdbm --with-threads --with-tls --with-threads=no gcc version 3.3.4, gdbm 1.8.3, OpenSSL 0.9.8e slapd core dumps with a corrupted stack, SIGABRT. slapd: cache.c:111: cache_return_entry_rw: Assertion `e->e_private != (( void *)0)' failed.. Happens every time ldif is loaded... $ ldapmodify -a -f ./mf.ldif -D "cn=Root,dc=mf" -w secret adding new entry "dc=mf" adding new entry "dc=iana,dc=mf" ldap_result: Can't contact LDAP server (-1)

1 0

Re: (ITS#5018) memory leak
by h.b.furuseth＠usit.uio.no 14 Jun '07

14 Jun '07

niloulili(a)hotmail.com writes: > if ( (ld = ldap_init("192.xxx.xxx.xxx",389 ))== NULL ) > return 1; > if ( ldap_simple_bind_s( ld,"CN=nina > wang,CN=Users,DC=ldap,DC=qtier,DC=com","0000" ) != LDAP_SUCCESS ) > { > ldap_perror( ld, "ldap_simple_bind_s" ); insert "ldap_unbind( ld );" here. Does that fix the problem? That's how to free the LDAP* structure. In LDAP, "unbind" is the "disconnect" command, it's not the opposite of "bind". The misleading name came about because originally one had to bind after connect. > return 1; > } > ldap_msgfree( res ); res == NULL here in this particular code, so you can drop this and the declaration of 'res'. > /* close and free connection resources */ > ldap_unbind( ld ); > return 0; > } -- Regards, Hallvard

1 0

Re: (ITS#5016) slapd generates unjustified error 3 (Time Limit Exceeded) at checkpoint time
by ando＠sys-net.it 14 Jun '07

14 Jun '07

ali.pouya(a)free.fr wrote: > What bothers me is that the regular client requests to the consumer receive > (scarcely and randomly) "Time Limit Exceeded" at checkpoint time. Would it be possible to get, from the consumer's log, what was the actually requested time limit in those cases? This means: track down what connection/operation was concluded by a "Time Limit Exceeded" response; then find out the corresponding request, and see what was the requested time limit. You need "args" debug level for this purpose, and you need to look at the second of the three numbers that end the SRCH line in the logs; for example: SRCH "dc=example,dc=com" 2 0 20 5 0 filter: (uid=foobar) attrs: 1.1 means: search "dc=example,dc=com" with scope subtree (2) and never deref aliases (0), using a size limit of 20, a timelimit of 5 and no attrsonly (0). 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#4943) tpool.c pause vs. finish
by h.b.furuseth＠usit.uio.no 14 Jun '07

14 Jun '07

Howard Chu writes: > Hallvard B Furuseth wrote: >> hyc(a)symas.com writes: >>> h.b.furuseth(a)usit.uio.no wrote: >>>> * When a thread is finishing, make it go active for context_reset(). >>>> Should make slapi module destructors safer, and I don't see that it >>>> can hurt. >>> I don't understand this. >> >> Let me dig a bit back in the ITS... >> "context_reset() can call connection_fake_destroy(), which via >> slapi_int_free_object_extensions() calls slapi module destructors, >> which can do who-knows-what." > > context_reset() can only be called from the main thread. It can (must) > never be called by anything running from the pool. It's called from pool_wrapper(). pool_wrapper() could go active so there can be no pause while that context_reset() call is running. >>>> * Scheduling: If several threads call pool_pause(), (...) (need to check out how it should work...) >>>> - pool_context() breaks if several ldap_pvt_thread_t bit patterns can >>>> represent the same thread ID: TID_HASH() would give different hashes >>>> for the same thread, and pool_context() stops searching when it hits >>>> a slot with ctx == NULL. (My previous bug report was a bit wrong.) >>> >>> How can a single thread ID be represented by multiple bit patterns? >> >> A struct/union with padding bytes seems the least unlikely possibility. Note that I did say "least unlikely" rather than "most likely": It's not that I expect to encounter it, more that I'd prefer not to be surprised in the form of a slapd malfuntion. So in that respect, my preference (not for RE23) is to cast to an integer for the hash, and also to add pthread_<set/get>specific() so thread_keys[] and its hash will only be a fallback solution. > Any implementation that leaves uninitialized padding bytes would be a > bug. Tools like valgrind would barf all over them. No. Valid compiler, valid code. Therefore valgrind is silent about copying uninitialized values, it only complains when you use them for something - like write() or arithmetic. So a valgrind complaint about an uninitialized _value_ isn't necessary at the point the uninitialized _variable_ is read. E.g. this complains in printf(), not in foo(): int foo() { struct { char c; /*maybe padding here*/ int j; } s; s.c = 1; s.j = 2; return ((unsigned char *)&s)[1]; /* maybe padding byte */ } int main() { printf("%d\n", foo()); } >> A pointer in hardware where several address representations map to the >> same physical address, and the compiler handles that by normalizing >> pointers when they are compared/subtracted. Like DOS "huge" pointers >> would have been if the compiler normalized them when comparing them >> instead of when incrementing/decrementing them. 20-bit address bus, >> 32-bit pointers, physical address = 16 * <segment half of pointer> + >> <offset half of pointer>. > > Nobody voluntarily uses such memory models today. The very mention of "DOS" > invalidates this discussion since there is no threading environment there. Right, at this point I answered how it _can_ happen, not why I expect to encounter it. I could see the demands of hardware design cause strange memory models to proliferate again, but I'm not holding my breath. I'd be a bit less surprised to encounter integers with padding bits again, but not for a simple ID type, and hashing an integer instead of its bytes would fix it anyway. >>> The best fix may be to just use the address of the thread's stack as the >>> thread ID. That's actually perfect for our purpose. >> >> How does a function called from somewhere inside the thread know that >> address? That's almost what the user context is, and thus what >> thread_keys[] maps the thread ID to. > > It requires some degree of machine-dependence, which is why I never > bothered to code it. The principle is simple though - all of our thread > stacks are some multiple of 1MB in size. Take the address of any local > variable, mask off the low 20 bits, and you have a unique thread ID (+/- > some additional masking/shifting based on the actual thread stack size). I'm not sure how to determine _which_ multiple of 1MB - start two threads and compare their stack addresses, maybe? In any case, I agree it sounds rather more machine-dependent than the current code. -- Regards, Hallvard

1 0

Re: (ITS#5016) slapd generates unjustified error 3 (Time Limit Exceeded) at checkpoint time
by ali.pouya＠free.fr 14 Jun '07

14 Jun '07

Selon Pierangelo Masarati <ando(a)sys-net.it>: > ali.pouya(a)free.fr wrote: > > > Hi, > > I use openldap 2.3.35 with the following bdb configuration. > > > > database bdb > > .... > > checkpoint 1000000 10 > > > > In my DB_CONFIG file I have : > > > > set_flags DB_LOG_AUTOREMOVE > > > > There ise a great LDAP read/write activity on my server. > > > > I notice that every 10 minutes some of my search requests receive randomly > an > > error 3 (Time Limit Exceeded) within one or two seconds while I'm using the > > slapd default timelimit (3600 seconds). > > > > I think a relation exists between this error and the checkpoint activity > (slapd > > is inclined to generate unjustified error 3 at checkpoint time) . > > Is it possible to study this problem ? > > > > I can send more information if required. > > > Do you mean that regular requests (to the producer or to the consumer?) > often receive "Time Limit Exceeded", or that the replication requests > issued by the consumer receive "Time Limit Exceeded" from the producer? > > 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 > --------------------------------------- > > > Hi Pierangelo; What bothers me is that the regular client requests to the consumer receive (scarcely and randomly) "Time Limit Exceeded" at checkpoint time. The replication requests to the master also receive this error after 3600 seconds when I'm synchronizing a new empty replica (as though I set timelimit unlimited for the sync client), but this is not a problem for me because the syncrepl client makes a new connection to the master and everything works well. Best regards Ali

1 0

Re: (ITS#5016) slapd generates unjustified error 3 (Time Limit Exceeded) at checkpoint time
by ando＠sys-net.it 14 Jun '07

14 Jun '07

ali.pouya(a)free.fr wrote: > Hi, > I use openldap 2.3.35 with the following bdb configuration. > > database bdb > .... > checkpoint 1000000 10 > > In my DB_CONFIG file I have : > > set_flags DB_LOG_AUTOREMOVE > > There ise a great LDAP read/write activity on my server. > > I notice that every 10 minutes some of my search requests receive randomly an > error 3 (Time Limit Exceeded) within one or two seconds while I'm using the > slapd default timelimit (3600 seconds). > > I think a relation exists between this error and the checkpoint activity (slapd > is inclined to generate unjustified error 3 at checkpoint time) . > Is it possible to study this problem ? > > I can send more information if required. Do you mean that regular requests (to the producer or to the consumer?) often receive "Time Limit Exceeded", or that the replication requests issued by the consumer receive "Time Limit Exceeded" from the producer? 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

(ITS#5018) memory leak
by niloulili＠hotmail.com 14 Jun '07

14 Jun '07

Full_Name: nina wang Version: 2.2.19 OS: Vxworks mips URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (222.68.187.35) I remove these code from linux to gcc. a computer equipmented os win 2000 server acts as server setting up AD . i start a thread to init a ldap connection and bind them with a valid account and password,configured in server. then unbind them every several seconds. through special tools ,i can see that free memory always being decreasing. if i only do action ldap_init,without bind to server,no the said scene . THE CODE IS : { LDAP *ld; LDAPMessage *res=NULL, *e; int i; char *a, *dn; BerElement *ptr; char **vals; /* open a connection */ if ( (ld = ldap_init("192.xxx.xxx.xxx",389 ))== NULL ) return 1; if ( ldap_simple_bind_s( ld,"CN=nina wang,CN=Users,DC=ldap,DC=qtier,DC=com","0000" ) != LDAP_SUCCESS ) { ldap_perror( ld, "ldap_simple_bind_s" ); return 1; } ldap_msgfree( res ); /* close and free connection resources */ ldap_unbind( ld ); return 0; } Hope to receive your response soon. Thank you .

1 0

Re: (ITS#5017) slapd generates unjustified error 3 (Time Limit Exceeded) at check
by ali.pouya＠free.fr 13 Jun '07

13 Jun '07

This ITS is a duplicate of ITS 5016. It is to be destroyed. Sorry for mis handling. Ali

1 0

(ITS#5017) slapd generates unjustified error 3 (Time Limit Exceeded) at checkpoint time
by ali.pouya＠free.fr 13 Jun '07

13 Jun '07

Full_Name: Ali Pouya Version: 2.3.35 OS: Linux RedHat AS4 (kernel 2.6) URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (145.242.3.30) Hi, I use openldap 2.3.35 with the following bdb configuration. database bdb .... checkpoint 1000000 10 In my DB_CONFIG file I have : set_flags DB_LOG_AUTOREMOVE There ise a great LDAP read/write activity on my server. I notice that every 10 minutes some of my search requests receive randomly an error 3 (Time Limit Exceeded) within one or two seconds while I'm using the slapd default timelimit (3600 seconds). I think a relation exists between this error and the checkpoint activity (slapd is inclined to generate unjustified error 3 at checkpoint time) . Is it possible to study this problem ? I can send more information if required. Thanks for your help Best regards Ali Pouya

1 0

(ITS#5016) slapd generates unjustified error 3 (Time Limit Exceeded) at checkpoint time
by ali.pouya＠free.fr 13 Jun '07

13 Jun '07

Full_Name: Ali Pouya Version: 2.3.35 OS: Linux RedHat AS4 (kernel 2.6) URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (145.242.3.30) Hi, I use openldap 2.3.35 with the following bdb configuration. database bdb .... checkpoint 1000000 10 In my DB_CONFIG file I have : set_flags DB_LOG_AUTOREMOVE There ise a great LDAP read/write activity on my server. I notice that every 10 minutes some of my search requests receive randomly an error 3 (Time Limit Exceeded) within one or two seconds while I'm using the slapd default timelimit (3600 seconds). I think a relation exists between this error and the checkpoint activity (slapd is inclined to generate unjustified error 3 at checkpoint time) . Is it possible to study this problem ? I can send more information if required. Thanks for your help Best regards Ali Pouya

1 0

(ITS#5015) pcache caches results of aborted searches
by rhafer＠suse.de 13 Jun '07

13 Jun '07

Full_Name: Ralf Haferkamp Version: RE23 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (89.166.165.45) Pcache will store the results of a search that got aborted (e.g. by hitting Ctrl+c during ldapsearch, oder using ldap_abandon) in it database. The next time the some query is issued it will answer the query from the cache, resulting in a incomplete result set. HEAD doesn't show this problem. Applying the changes from result.c r.1.289 to RE23 seems to fix this problem.

1 0

RE: Native Win32 build with WGCC/Interix (ITS#4825)
by Markus.Duft＠salomon.at 13 Jun '07

13 Jun '07

Hi! First thanks for reviewing the patch! Howard Chu <mailto:openldap-its@OpenLDAP.org> wrote: > I have not tested this patch, but it does not appear to be correct. > > In ldap_cdefs.h, you should not be testing the PIC macro since that > controls whether the current source file is being built as > position-independent. The macro you actually need to test is > LDAP_LIBS_DYNAMIC, just as the regular WIN32 case tests. Note that > the current macros work fine for both MSVC and MinGW/gcc; I don't see > why you've chosen to change the LBER_F definitions for your wgcc. Uh.. I'd have to look into that again ;o) Still this works fine since some time now, and the libraries are under heavy usage at our company... > > Likewise, your hack to portable.hin should not be necessary, as all > of the places that use sockets or timevals already include the > appropriate header files. Again, i'd have to look at this again... > > The patch to ure.h seems unnecessary, since the file exists at both > locations (the original, and via symlink). Smylinks are not supported when windows building on interix ;o// This caused some troubles as far as i remember. > > Finally, unless you're using a flag to force all symbols to be > exported, I think omitting slapd.exp in the slapd/Makefile.in is a > mistake. WGCC automatically exports/imports correctly. > > Really, the comments in ldap_cdefs.h are pretty explicit about why > each piece of the current Windows support is as it is. Your patch > seems to preclude some of the combinations of DLL/static linking that > we went to great pains to support. WGCC claims to support (with this patch) *all* possible static/shared combinations (without pain ;o)). WGCC generates code to support static libraries, even if it was compiled like a shared library (with __declspec(dllimport)'s, etc.), so most of the painfull stuff is not needed. On the other hand to support *all* configurations, one needs to allway dllimport, so both shared and static work ... > > For the include/Makefile.in it would probably have made more sense to > define a WINPATH macro to either "cygpath -w" or "unixpath2win" and > use that, rather than repeating all of the SED invocations. Yes, it would have been better, but it's a long time since i wrote the patch, and now i'd propably do more things differently ;o) > > These days I wonder whether it wouldn't be smarter to just remove all > of the special casing for braindead backslash directory separators. > Since Windows now supports forward slashes everywhere, it would make > life easier to just use forward slashes consistently throughout. Would be cool, but still path handling functions from windows return paths with backslashes, so those would need to be handled too.. Cheers, Markus -- 20. Juni 2007 Salomon Automation am 2. Schweizerischen Supply Chain Management Forum der GS1 Schweiz in Baden. Tagungsort: Trafohalle Baden, Schweiz 20. Juni 2007 MoveRetail-Handelstag, Hamburg Die MoveRetail Partner, Salomon Automation, maxess systemhaus, Superdata, Remira, POS Systemhaus und Mosaic veranstalten den 1. MoveRetail-Handelstag. Tagungsort: Steigenberger Hotel, Hamburg 28. Juni 2007 6. BVL Logistiktag Steiermark in der WAMAS City, Friesach bei Graz "Trends in der Logistik ": hoch automatisierte Systeme, mobile Waren- und Leergutverfolgung im Lebensmittelhandel und Generalunternehmerschaft versus Einzelprojekte. Termin: 28. Juni 2007, ab 15.00 Uhr Ort: Salomon Automation, Friesachstra?e 15, 8114 Friesach bei Graz, Osterreich Salomon Automation GmbH - Friesachstrasse 15 - A-8114 Friesach bei Graz Sitz der Gesellschaft: Friesach bei Graz UID-NR:ATU28654300 - Firmenbuchnummer: 49324 K Firmenbuchgericht: Landesgericht fur Zivilrechtssachen Graz

1 0

Re: (ITS#4943) tpool.c pause vs. finish
by hyc＠symas.com 12 Jun '07

12 Jun '07

Hallvard B Furuseth wrote: > hyc(a)symas.com writes: >> h.b.furuseth(a)usit.uio.no wrote: >>> * When a thread is finishing, make it go active for context_reset(). >>> Should make slapi module destructors safer, and I don't see that it >>> can hurt. >> I don't understand this. > > Let me dig a bit back in the ITS... > "context_reset() can call connection_fake_destroy(), which via > slapi_int_free_object_extensions() calls slapi module destructors, > which can do who-knows-what." context_reset() can only be called from the main thread. It can (must) never be called by anything running from the pool. >>> * Scheduling: If several threads call pool_pause(), then once there is a >>> pause tpool does not schedule them all. They could get handled then, >>> or another thread could undo the pause so tpool would wait to pause >>> again. Is that deliberate? >> I don't understand the question. The point of the pause is to prevent >> any other thread (in the pool) from running. Why should tpool schedule >> any other threads at this point? > > Two threads call pool_pause(). Eventually the pool gets paused, and one > pool_pause() call returns. When that thread calls pool_resume(), the > other thread waiting in pool_pause() may or may not get scheduled. OK, that sounds like a bug. >>> - pool_context() breaks if several ldap_pvt_thread_t bit patterns can >>> represent the same thread ID: TID_HASH() would give different hashes >>> for the same thread, and pool_context() stops searching when it hits >>> a slot with ctx == NULL. (My previous bug report was a bit wrong.) >> How can a single thread ID be represented by multiple bit patterns? > > A struct/union with padding bytes seems the least unlikely possibility. Any implementation that leaves uninitialized padding bytes would be a bug. Tools like valgrind would barf all over them. > A pointer in hardware where several address representations map to the > same physical address, and the compiler handles that by normalizing > pointers when they are compared/subtracted. Like DOS "huge" pointers > would have been if the compiler normalized them when comparing them > instead of when incrementing/decrementing them. 20-bit address bus, > 32-bit pointers, physical address = 16 * <segment half of pointer> + > <offset half of pointer>. Nobody voluntarily uses such memory models today. The very mention of "DOS" invalidates this discussion since there is no threading environment there. >>> The best fix would be to use use real thread-specific data instead. >>> Just one key with the ctx for now, that minimizes the changes. OTOH >>> it also means we'll do thread-specific key lookup twice - first in >>> pthread to get the ctx, and then in ltu_key[] to find our data. >>> Anyway, I said I'd do that later but might as well get on with it, >>> at least for pthreads. Except I don't know if that's OS-dependent >>> enough that it should wait for RE24? >> The best fix may be to just use the address of the thread's stack as the >> thread ID. That's actually perfect for our purpose. > > How does a function called from somewhere inside the thread know that > address? That's almost what the user context is, and thus what > thread_keys[] maps the thread ID to. It requires some degree of machine-dependence, which is why I never bothered to code it. The principle is simple though - all of our thread stacks are some multiple of 1MB in size. Take the address of any local variable, mask off the low 20 bits, and you have a unique thread ID (+/- some additional masking/shifting based on the actual thread stack size). -- -- 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#4983) libldap_r/tls.c compile failure
by h.b.furuseth＠usit.uio.no 12 Jun '07

12 Jun '07

I wrote: > For whatever isn't handled above, my suggestion for now is to keep the > failure if ldap_pvt_thread_t is a struct/union or wider than long, and > see if anyone still complains. Done. Compiles unless pointers are wider than long, but the basic problem remains. -- Regards, Hallvard

1 0

Re: (ITS#5010) broken ber_encode_oid/ber_decode_oid()
by h.b.furuseth＠usit.uio.no 12 Jun '07

12 Jun '07

I wrote: > Finally, libldap/tls.c does not check if ber_decode_oid() fails. Fixed that. Waiting for the other stuff, depends on the code's intent. -- Regards, Hallvard

1 0

(ITS#5014) syncrepl failure syslog
by donn＠u.washington.edu 12 Jun '07

12 Jun '07

Full_Name: Donn Cave Version: 2.4.4 OS: Red Hat RHEL 3 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (128.95.135.150) Hard to tell why syncrepl isn't working, if it discards error messages. *** servers/slapd/syncrepl.c.dist 2007-02-15 17:53:39.000000000 -0800 --- servers/slapd/syncrepl.c 2007-06-12 13:35:22.000000000 -0700 *************** *** 688,694 **** struct sync_cookie syncCookie_req = { NULL }; struct berval cookie = BER_BVNULL; ! int rc, err; ber_len_t len; struct berval *psub; --- 688,694 ---- struct sync_cookie syncCookie_req = { NULL }; struct berval cookie = BER_BVNULL; ! int rc, err, rrc; ber_len_t len; struct berval *psub; *************** *** 704,709 **** --- 704,710 ---- BerVarray syncUUIDs = NULL; ber_tag_t si_tag; + rrc = LDAP_SUCCESS; if ( slapd_shutdown ) { rc = -2; goto done; *************** *** 727,732 **** --- 728,734 ---- while ( ( rc = ldap_result( si->si_ld, LDAP_RES_ANY, LDAP_MSG_ONE, tout_p, &res ) ) > 0 ) { + ldap_parse_result( si->si_ld, res, &rrc, 0, 0, 0, 0, 0 ); if ( slapd_shutdown ) { rc = -2; goto done; *************** *** 1061,1066 **** --- 1063,1076 ---- } done: + if ( rrc != LDAP_SUCCESS ) { + const char *errstr; + ldap_get_option( si->si_ld, LDAP_OPT_ERROR_NUMBER, &rrc ); + errstr = ldap_err2string( rrc ); + + Debug( LDAP_DEBUG_ANY, + "syncrepl %s result: %s\n", si->si_ridtxt, errstr, 0 ); + } slap_sync_cookie_free( &syncCookie, 0 ); slap_sync_cookie_free( &syncCookie_req, 0 );

1 0

Re: (ITS#4996) Use SRV records to locate local server for command-line clients
by rra＠stanford.edu 11 Jun '07

11 Jun '07

ando <ando(a)sys-net.it> writes: > Committed to HEAD. Command-line clients now use DNS SRV to look up the > host names related to a DN and build a list of URIs for subsequent use. > To trigger, use -H "<proto>:///DN". The <host> portion must be empty, > and a DN must be present. The DN must be in the "dc=<component>" form; > it's turned into a domain and the host list is looked up using DNS SRV. > After that, a list of URIs is built using the returned host/ports, and > using <proto> as the LDAP scheme. Thank you! I've forwarded this information to the original Debian bug reporter who was interested in the feature in the hopes that he'll be able to test and provide feedback on the implementation. -- Russ Allbery (rra(a)stanford.edu) <http://www.eyrie.org/~eagle/>

1 0

Re: (ITS#5011) loglevel packet doesn't work
by ando＠sys-net.it 11 Jun '07

11 Jun '07

ando(a)sys-net.it wrote: > ... it's "packets". The man page (or the code) is wrong. ... but the man page is correct in HEAD; so it was fixed, but not backported. 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#5011) loglevel packet doesn't work
by ando＠sys-net.it 11 Jun '07

11 Jun '07

quanah(a)zimbra.com wrote: > Full_Name: Quanah Gibson-Mount > Version: 2.3.35 > OS: mac os x > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (66.92.25.194) > > > The slapd.conf man page says: > > loglevel <integer> [...] > 2 (0x2 packet) debug packet handling > > but if you specify packet, slapd refuses to start, stating: > > /opt/zimbra/openldap-2.3.35.7/etc/openldap/slapd.conf: line 53: <loglevel> > unknown level "packet" ... it's "packets". The man page (or the code) is wrong. 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

(ITS#5011) loglevel packet doesn't work
by quanah＠zimbra.com 11 Jun '07

11 Jun '07

Full_Name: Quanah Gibson-Mount Version: 2.3.35 OS: mac os x URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (66.92.25.194) The slapd.conf man page says: loglevel <integer> [...] 2 (0x2 packet) debug packet handling but if you specify packet, slapd refuses to start, stating: /opt/zimbra/openldap-2.3.35.7/etc/openldap/slapd.conf: line 53: <loglevel> unknown level "packet" --Quanah

1 0

Re: (ITS#5008) Do you have the win32 version of OpenLDAP
by h.b.furuseth＠usit.uio.no 11 Jun '07

11 Jun '07

caojunliang(a)huawei.com writes: > I want to know whether or not the win32 version of OpenLDAP exsits. Please take this to the mailinglist openldap-software(a)openldap.org. The Issue Tracking System is for bug reports etc, not for help requests. This ITS will be closed. -- Regards, Hallvard

1 0

(ITS#5010) broken ber_encode_oid/ber_decode_oid()
by h.b.furuseth＠usit.uio.no 11 Jun '07

11 Jun '07

Full_Name: Hallvard B Furuseth Version: HEAD OS: URL: http://folk.uio.no/hbf/OpenLDAP/oid-encdec.txt Submission from: (NULL) (129.240.202.105) Submitted by: hallvard The 40*X+Y rule for first 2 components is decoded wrong, it should be X = val < 80 ? val/40 : 2 # X = 0, 1 or 2 Y = val - 40*X # Y is unlimited when X==2, <40 otherwise See X.690 8.19.4: ... (X*40) + Y: NOTE - This packing of the first two object identifier components recognizes that only three values are allocated from the root node, and at most 39 subsequent values from nodes reached by X = 0 and X = 1. 40*X+Y can take more than one octet. The functions allow buffer overruns. ber_decode_oid() if the oid has many small components. ber_encode_oid() for negative input (which becomes a large ulong), or if sizeof(long) == 8. The latter can just as easily be avoided by producing the bytes backwards and then reversing. They do not check much for invalid input or too large values. Possibly they ought to be a bit paranoid about that since they are used for certificates, I don't know. E.g. check that the BER encoding has "fewest possible octets" (X.690 8.19.2), i.e. no initial 0x80 in subidentifiers. ber_encode_oid() seems a bit strange about which errors it accepts and which ones it rejects. E.g. garbage after first 2 components is OK. The "assert(foo != NULL)"s are after "der = foo->bv_val":-) I enclose untested new versions. Will test and commit when I have time if someone says OK, but it depends e.g. on how paranoid the routines should or should not be. Or if they should trust the ber values to end with \0, for that matter. Finally, libldap/tls.c does not check if ber_decode_oid() fails.

1 0

Re: (ITS#5009) ldapsearch -C not in manpage
by dustin＠puryear-it.com 11 Jun '07

11 Jun '07

Thinking about this further, it looks like the manpage is really deferring to 'ldapsearch --help' since that is where the meat of the documentation is. There is some potential confusion here I think. What if the manpage just refers the reader to 'ldapsearch --help' for complete information? -- Puryear Information Technology, LLC Baton Rouge, LA * 225-706-8414 http://www.puryear-it.com Author: "Best Practices for Managing Linux and UNIX Servers" "Spam Fighting and Email Security in the 21st Century" Download your free copies: http://www.puryear-it.com/pubs/ebooks/

1 0

Re: (ITS#5009) ldapsearch -C not in manpage
by dustin＠puryear-it.com 11 Jun '07

11 Jun '07

By the way, I did verify that -C does work. It simply isn't in the manpage. Also, a quick grep of the binary: [root@samba openldap]# strings /usr/bin/ldapsearch | grep -- -C -C chase referrals (anonymously) This is a low priority documentation bug only. The binary works fine. -- Puryear Information Technology, LLC Baton Rouge, LA * 225-706-8414 http://www.puryear-it.com Author: "Best Practices for Managing Linux and UNIX Servers" "Spam Fighting and Email Security in the 21st Century" Download your free copies: http://www.puryear-it.com/pubs/ebooks/

1 0

(ITS#5009) ldapsearch -C not in manpage
by dustin＠puryear-it.com 11 Jun '07

11 Jun '07

Full_Name: Dustin Puryear Version: 2.213-7 OS: CentOS 4.3 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (72.242.176.166) The -C flag is not in the ldapsearch manpage. # rpm -q -a | grep openldap openldap-2.2.13-7.4E openldap-devel-2.2.13-7.4E openldap-servers-2.2.13-7.4E openldap-clients-2.2.13-7.4E # # man ldapsearch | grep -- -C # Alias info is there: # man ldapsearch | grep -- -a [-s base|one|sub] [-a never|always|search|find] [-l timelimit] ldapsearch is a shell-accessible interface to the ldap_search(3) -a never|always|search|find audio:< file:///tmp/ldapsearch-audio-a19924 jpegPhoto:< file:///tmp/ldapsearch-jpegPhoto-a19924 # # man ldapsearch | tail The OpenLDAP Project <http://www.openldap.org/> ACKNOWLEDGEMENTS OpenLDAP is developed and maintained by The OpenLDAP Project (http://www.openldap.org/). OpenLDAP is derived from University of Michigan LDAP 3.3 Release. OpenLDAP 2.2.13 2004/06/10 LDAPSEARCH(1) # # cat /etc/redhat-release CentOS release 4.3 (Final) #

1 0

Re: (ITS#5005) test017 fails
by ando＠sys-net.it 11 Jun '07

11 Jun '07

dieter(a)dkluenter.de wrote: > the patch fails, this is the patch reject file: That's probably because you cut'n'pasted from the email, where the tabs were probably replaced by whitespaces. I'll apply that fix if anyone confirms that cookie is legal at all. 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#5005) test017 fails
by dieter＠dkluenter.de 10 Jun '07

10 Jun '07

Quanah Gibson-Mount <quanah(a)zimbra.com> writes: > --On June 8, 2007 6:43:50 PM +0000 dieter(a)dkluenter.de wrote: > >> Full_Name: Dieter Kluenter >> Version: HEAD >> OS: Linux >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (84.142.196.121) >> >> >> here the output of test017 logfiles >> >> ---slapd.1.log---------------- >> ber_scanf fmt (}) ber: >> <= get_ctrls: n=1 rc=2 err="Sync control : cookie parsing error" >> send_ldap_result: conn=7 op=1 p=3 >> send_ldap_result: err=2 matched="" text="Sync control : cookie parsing >> error" send_ldap_response: msgid=2 tag=101 err=2 > > Hm, is this possibly related to the fix for ITS#4977? If you revert > that checkin for syncprov.c today, does the test pass? > > > <http://www.openldap.org/devel/cvsweb.cgi/servers/slapd/overlays/syncprov.c.…> Unfortunately no chance, still the same error. -Dieter -- Dieter Klünter | Systemberatung http://www.dkluenter.de GPG Key ID:8EF7B6C6

1 0

Re: (ITS#5005) test017 fails
by dieter＠dkluenter.de 10 Jun '07

10 Jun '07

Pierangelo Masarati <ando(a)sys-net.it> writes: > dieter(a)dkluenter.de wrote: > > The problem is in slap_parse_sync_cookie(); when no cookie is passed, a > string containing "rid=001" is parsed. The parser expects it to end > with a comma. If passing "rid=001" is correct, the fix is trivial: > instead of checking for (*next != ','), check for (*next && *next != ','). > > Index: servers/slapd/ldapsync.c > =================================================================== > RCS file: /repo/OpenLDAP/pkg/ldap/servers/slapd/ldapsync.c,v > retrieving revision 1.42 > diff -u -r1.42 ldapsync.c > --- servers/slapd/ldapsync.c 18 May 2007 12:46:52 -0000 1.42 > +++ servers/slapd/ldapsync.c 9 Jun 2007 09:42:24 -0000 > @@ -180,7 +180,10 @@ > if ( !strncmp( next, "rid=", STRLENOF("rid=") )) { > rid_ptr = next; > cookie->rid = strtoul( &rid_ptr[ STRLENOF( > "rid=" ) ], &next, 10 ); > - if ( next == rid_ptr || next > end || *next != > ',' ) { > + if ( next == rid_ptr > + || next > end > + || ( *next && *next != ',' ) ) > + { > return -1; > } > if ( *next == ',' ) { > @@ -194,7 +197,10 @@ > if ( !strncmp( next, "sid=", STRLENOF("sid=") )) { > rid_ptr = next; > cookie->sid = strtoul( &rid_ptr[ STRLENOF( > "sid=" ) ], &next, 16 ); > - if ( next == rid_ptr || next > end || *next != > ',' ) { > + if ( next == rid_ptr > + || next > end > + || ( *next && *next != ',' ) ) > + { > return -1; > } > if ( *next == ',' ) { > > I'm not committing this fix because I'm not sure it doesn't break > anything else. the patch fails, this is the patch reject file: ---ldapsync.c.rej ------------------------------- *************** *** 180,186 **** if ( !strncmp( next, "rid=", STRLENOF("rid=") )) { rid_ptr = next; cookie->rid = strtoul( &rid_ptr[ STRLENOF( "rid=" ) ], &next, 10 ); - if ( next == rid_ptr || next > end || *next != ',' ) { return -1; } if ( *next == ',' ) { --- 180,189 ---- if ( !strncmp( next, "rid=", STRLENOF("rid=") )) { rid_ptr = next; cookie->rid = strtoul( &rid_ptr[ STRLENOF( "rid=" ) ], &next, 10 ); + if ( next == rid_ptr + || next > end + || ( *next && *next != ',' ) ) + { return -1; } if ( *next == ',' ) { *************** *** 194,200 **** if ( !strncmp( next, "sid=", STRLENOF("sid=") )) { rid_ptr = next; cookie->sid = strtoul( &rid_ptr[ STRLENOF( "sid=" ) ]. &next, 16 ); - if ( next == rid_ptr || next > end || *next != ',' ) { return -1; } if ( *next == ',' ) { --- 197,206 ---- if ( !strncmp( next, "sid=", STRLENOF("sid=") )) { rid_ptr = next; cookie->sid = strtoul( &rid_ptr[ STRLENOF( "sid=" ) ]. &next, 16 ); + if ( next == rid_ptr + || next > end + || ( *next && *next != ',' ) ) + { return -1; } if ( *next == ',' ) { -Dieter -- Dieter Klünter | Systemberatung http://www.dkluenter.de GPG Key ID:8EF7B6C6

1 0

Re: (ITS#4629) slapd failure on HP-UX 11.23/IA 64-bit
by h.b.furuseth＠usit.uio.no 10 Jun '07

10 Jun '07

Fixed in cvs (RE23 and HEAD) with a somewhat different patch. It should be more comprehensive than the old one, but testing on various systems is welcome anyway. -- Regards, Hallvard

1 0

Re: (ITS#4936) default modulepath
by ando＠sys-net.it 10 Jun '07

10 Jun '07

> No, they are installed in $(moduledir), which depends on LDAP_LIBEXECDIR > and --with-subdir. So, put that in some C variable or #define. Yes, I figured that out. I'll fix this later. 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#4936) default modulepath
by h.b.furuseth＠usit.uio.no 10 Jun '07

10 Jun '07

I wrote: > Use LDAP_LIBEXECDIR/openldap/, that's where modules get installed. > Try with ./configure --enable-overlays=mod --enable-monitor=mod. No, they are installed in $(moduledir), which depends on LDAP_LIBEXECDIR and --with-subdir. So, put that in some C variable or #define. -- Regards, Hallvard

1 0

(ITS#5007) Compilation problems
by h.b.furuseth＠usit.uio.no 09 Jun '07

09 Jun '07

Full_Name: Hallvard B Furuseth Version: HEAD, RE23 OS: HP-UX, OSF1, non-gcc URL: Submission from: (NULL) (129.240.202.105) Submitted by: hallvard HEAD/RE23: liblber/sockbuf.c uses pointer arithmetic on void*, a gcc extension. HEAD: OSF1 pthread.h defines "leave" as an exception keyword, which breaks slapd and bdb. I'll rename "leave" labels to "done" or "finish". liblutil/getpeereid.c breaks if LDAP_PF_LOCAL_SENDMSG is defined but MSG_WAITALL is not. (Not sure why that's compiled at all after the ldapi trouble, but that's another matter.) I'll fix it by #ifdeffing MSG_WAITALL in getpeereid.c rather than where LDAP_PF_LOCAL_SENDMSG is defined, since we need LDAP_PF_LOCAL_SENDMSG to decide whether to send a dummy abandon to previous OpenLDAP server versions.

1 0

Re: (ITS#4936) default modulepath
by h.b.furuseth＠usit.uio.no 09 Jun '07

09 Jun '07

ando(a)sys-net.it writes: > It would be pretty straightforward to call lt_dlsetsearchpath() > (actually, the module_path() wrapper) from module_init() with a default > value. This could be, for example, LDAP_LIBEXECDIR, where slapd itself > gets installed by default. Use LDAP_LIBEXECDIR/openldap/, that's where modules get installed. Try with ./configure --enable-overlays=mod --enable-monitor=mod. -- Regards, Hallvard

1 0

Re: (ITS#4996) Use SRV records to locate local server for command-line clients
by ando＠sys-net.it 09 Jun '07

09 Jun '07

Committed to HEAD. Command-line clients now use DNS SRV to look up the host names related to a DN and build a list of URIs for subsequent use. To trigger, use -H "<proto>:///DN". The <host> portion must be empty, and a DN must be present. The DN must be in the "dc=<component>" form; it's turned into a domain and the host list is looked up using DNS SRV. After that, a list of URIs is built using the returned host/ports, and using <proto> as the LDAP scheme. Please test. 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#4936) default modulepath
by ando＠sys-net.it 09 Jun '07

09 Jun '07

It would be pretty straightforward to call lt_dlsetsearchpath() (actually, the module_path() wrapper) from module_init() with a default value. This could be, for example, LDAP_LIBEXECDIR, where slapd itself gets installed by default. Comments? 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#4943) tpool.c pause vs. finish
by h.b.furuseth＠usit.uio.no 09 Jun '07

09 Jun '07

I wrote: > I'll just make [the hash table] chained. (...) > Solves the multi-pool problem too. No it doesn't. pool_pause() would stilll only pause one pool, while purgekey() needs all pools to be paused. I guess I'll chain it anyway. I forgot one bug in my summary: Slapd does not always check if pool_submit() and pool_setkey() succeed, even though failure is not a bug. (They can run into some limits.) pool_submit(): daemon.c:slapd_daemon_task() with rtask->routine connection.c:connections_shutdown() with c_clientfunc connection.c:connection_read() with c_clientfunc back-bdb/tools.c:bdb_tool_entry_open() with trickle and index tasks pool_setkey(): connection.c:connection_fake_init2() for slapi object extensions backend.c:be_isroot_pw() for SLAPD_SPASSWD passwd.c:slap_passwd_check() for SLAPD_SPASSWD sl_malloc.c:slap_sl_mem_create() back-bdb/search.c:search_stack() back-meta/conn.c:meta_back_candidates_get() slapd-modules/smbk5pwd/smbk5pwd.c:smbk5pwd_op_bind() -- Regards, Hallvard

1 0

Re: (ITS#4986) manageDSAit might control cause problems in database selection
by ando＠sys-net.it 09 Jun '07

09 Jun '07

A tentative fix is in HEAD (servers/slapd/backend.c 1.377 -> 1.378). Please test. 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

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs