- openldap-bugs - openldap.org

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

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs