openldap-bugs

openldap-bugs@openldap.org

1 participants
20961 discussions

(ITS#6380) slap_sl_free is too lazy
by hyc＠OpenLDAP.org 15 Nov '09

15 Nov '09

Full_Name: Howard Chu Version: 2.4 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (76.91.220.157) Submitted by: hyc slap_sl_free() would only reclaim memory if you were freeing the last allocated block. If you wanted to free a chain of alloc'd memory you would have to free them in the exact reverse order of allocation. Calling slap_sl_free() out of order would be a no-op. This was OK most of the time because a single operation would seldom live long enough to use much memory. But for long-lived tasks (like syncrepl or syncprov) it would often run out and allocs would fallback to ch_malloc. sl_malloc.c in HEAD has been changed to mark freed blocks no matter what order they're freed in. It still only reclaims from the last block forward, but it's more effective now.

1 0

Re: (ITS#6377) test058-syncrepl-asymmetric failed for bdb (exit 3)
by hyc＠symas.com 15 Nov '09

15 Nov '09

Michael Ströder wrote: > hyc(a)symas.com wrote: >> hyc(a)symas.com wrote: >>> I'm seeing the same problem here. Still haven't identified the cause, looking... >>> >> Fixed. > > HEAD now has a different issue. Is this related to this fix? Now fixed. >>>>>> Starting test003-search for bdb... -- -- Howard Chu CTO, 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#6377) test058-syncrepl-asymmetric failed for bdb (exit 3)
by hyc＠symas.com 15 Nov '09

15 Nov '09

Michael Ströder wrote: > hyc(a)symas.com wrote: >> hyc(a)symas.com wrote: >>> I'm seeing the same problem here. Still haven't identified the cause, looking... >>> >> Fixed. > > HEAD now has a different issue. Is this related to this fix? Since test003 doesn't involve sync replication in any way, no. This ITS is fixed, closing. File a separate ITS for different issues... -- -- Howard Chu CTO, 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#6377) test058-syncrepl-asymmetric failed for bdb (exit 3)
by michael＠stroeder.com 15 Nov '09

15 Nov '09

hyc(a)symas.com wrote: > hyc(a)symas.com wrote: >> I'm seeing the same problem here. Still haven't identified the cause, looking... >> > Fixed. HEAD now has a different issue. Is this related to this fix? Ciao, Michael. >>>>> Starting test003-search for bdb... running defines.sh Running slapadd to build slapd database... Running slapindex to index slapd database... Starting slapd on TCP/IP port 9011... Testing slapd searching... Testing exact searching... Testing approximate searching... Testing OR searching... *** glibc detected *** /usr/src/michael/openldap/HEAD/openldap/servers/slapd/.libs/lt-slapd: free(): invalid pointer: 0x000000000 097fb28 *** ======= Backtrace: ========= /lib64/libc.so.6[0x2b2f801d5c76] /lib64/libc.so.6(cfree+0x6c)[0x2b2f801da96c] /usr/src/michael/openldap/HEAD/openldap/libraries/liblber/.libs/liblber-2-devel.so.0(ber_bvarray_free_x+0x63)[0x2b2f7e30f273] ../servers/slapd/back-bdb/.libs/back_bdb-2-devel.so.0(bdb_filter_candidates+0x1752)[0x2b2f82889842] ../servers/slapd/back-bdb/.libs/back_bdb-2-devel.so.0[0x2b2f82889f07] ../servers/slapd/back-bdb/.libs/back_bdb-2-devel.so.0(bdb_filter_candidates+0x5aa)[0x2b2f8288869a] ../servers/slapd/back-bdb/.libs/back_bdb-2-devel.so.0[0x2b2f82889f07] ../servers/slapd/back-bdb/.libs/back_bdb-2-devel.so.0(bdb_filter_candidates+0x5aa)[0x2b2f8288869a] ../servers/slapd/back-bdb/.libs/back_bdb-2-devel.so.0[0x2b2f82889f07] ../servers/slapd/back-bdb/.libs/back_bdb-2-devel.so.0(bdb_filter_candidates+0x79a)[0x2b2f8288888a] ../servers/slapd/back-bdb/.libs/back_bdb-2-devel.so.0(bdb_search+0xe96)[0x2b2f82882cf6] /usr/src/michael/openldap/HEAD/openldap/servers/slapd/.libs/lt-slapd(fe_op_search+0x259)[0x436c29] /usr/src/michael/openldap/HEAD/openldap/servers/slapd/.libs/lt-slapd(do_search+0x6ac)[0x43743c] /usr/src/michael/openldap/HEAD/openldap/servers/slapd/.libs/lt-slapd[0x434a01] /usr/src/michael/openldap/HEAD/openldap/servers/slapd/.libs/lt-slapd[0x435285] /usr/src/michael/openldap/HEAD/openldap/libraries/libldap_r/.libs/libldap_r-2-devel.so.0[0x2b2f7e0cb1b8] /lib64/libpthread.so.0[0x2b2f7ecdc65d] /lib64/libc.so.6(clone+0x6d)[0x2b2f8023414d] ======= Memory map: ======== 00400000-00529000 r-xp 00000000 08:05 524931 /usr/src/michael/openldap/HEAD/openldap/servers/slapd/.l ibs/lt-slapd 00728000-00729000 r--p 00128000 08:05 524931 /usr/src/michael/openldap/HEAD/openldap/servers/slapd/.l ibs/lt-slapd 00729000-00730000 rw-p 00129000 08:05 524931 /usr/src/michael/openldap/HEAD/openldap/servers/slapd/.l ibs/lt-slapd 00730000-00aa2000 rw-p 00000000 00:00 0 [heap] 2b2f7de9a000-2b2f7deb8000 r-xp 00000000 08:05 145546 /lib64/ld-2.10.1.so 2b2f7deb8000-2b2f7deba000 rw-p 00000000 00:00 0 2b2f7e0b7000-2b2f7e0b8000 r--p 0001d000 08:05 145546 /lib64/ld-2.10.1.so 2b2f7e0b8000-2b2f7e0b9000 rw-p 0001e000 08:05 145546 /lib64/ld-2.10.1.so 2b2f7e0b9000-2b2f7e102000 r-xp 00000000 08:05 524531 /usr/src/michael/openldap/HEAD/openldap/libraries/liblda p_r/.libs/libldap_r-2-devel.so.0.0.0 2b2f7e102000-2b2f7e301000 ---p 00049000 08:05 524531 /usr/src/michael/openldap/HEAD/openldap/libraries/liblda p_r/.libs/libldap_r-2-devel.so.0.0.0 2b2f7e301000-2b2f7e302000 r--p 00048000 08:05 524531 /usr/src/michael/openldap/HEAD/openldap/libraries/liblda p_r/.libs/libldap_r-2-devel.so.0.0.0 2b2f7e302000-2b2f7e304000 rw-p 00049000 08:05 524531 /usr/src/michael/openldap/HEAD/openldap/libraries/liblda p_r/.libs/libldap_r-2-devel.so.0.0.0 2b2f7e304000-2b2f7e307000 rw-p 00000000 00:00 0 2b2f7e307000-2b2f7e314000 r-xp 00000000 08:05 524374 /usr/src/michael/openldap/HEAD/openldap/libraries/liblbe r/.libs/liblber-2-devel.so.0.0.0 2b2f7e314000-2b2f7e513000 ---p 0000d000 08:05 524374 /usr/src/michael/openldap/HEAD/openldap/libraries/liblbe r/.libs/liblber-2-devel.so.0.0.0 2b2f7e513000-2b2f7e514000 r--p 0000c000 08:05 524374 /usr/src/michael/openldap/HEAD/openldap/libraries/liblbe r/.libs/liblber-2-devel.so.0.0.0 2b2f7e514000-2b2f7e515000 rw-p 0000d000 08:05 524374 /usr/src/michael/openldap/HEAD/openldap/libraries/liblbe r/.libs/liblber-2-devel.so.0.0.0 2b2f7e531000-2b2f7e532000 rw-p 00000000 00:00 0 2b2f7e532000-2b2f7e535000 r-xp 00000000 08:05 166857 /lib64/libuuid.so.1.3.0 2b2f7e535000-2b2f7e735000 ---p 00003000 08:05 166857 /lib64/libuuid.so.1.3.0 2b2f7e735000-2b2f7e736000 r--p 00003000 08:05 166857 /lib64/libuuid.so.1.3.0 2b2f7e736000-2b2f7e737000 rw-p 00004000 08:05 166857 /lib64/libuuid.so.1.3.0 2b2f7e737000-2b2f7e866000 r-xp 00000000 08:05 198841 /usr/lib64/libdb-4.5.so 2b2f7e866000-2b2f7ea65000 ---p 0012f000 08:05 198841 /usr/lib64/libdb-4.5.so 2b2f7ea65000-2b2f7ea68000 r--p 0012e000 08:05 198841 /usr/lib64/libdb-4.5.so 2b2f7ea68000-2b2f7ea6b000 rw-p 00131000 08:05 198841 /usr/lib64/libdb-4.5.so 2b2f7ea6b000-2b2f7eacd000 r-xp 00000000 08:05 235428 /usr/lib64/libodbc.so.1.0.0 2b2f7eacd000-2b2f7eccc000 ---p 00062000 08:05 235428 /usr/lib64/libodbc.so.1.0.0 2b2f7eccc000-2b2f7eccd000 r--p 00061000 08:05 235428 /usr/lib64/libodbc.so.1.0.0 2b2f7eccd000-2b2f7ecd4000 rw-p 00062000 08:05 235428 /usr/lib64/libodbc.so.1.0.0 2b2f7ecd4000-2b2f7ecd6000 rw-p 00000000 00:00 0 2b2f7ecd6000-2b2f7ecec000 r-xp 00000000 08:05 156951 /lib64/libpthread-2.10.1.so 2b2f7ecec000-2b2f7eeec000 ---p 00016000 08:05 156951 /lib64/libpthread-2.10.1.so 2b2f7eeec000-2b2f7eeed000 r--p 00016000 08:05 156951 /lib64/libpthread-2.10.1.so 2b2f7eeed000-2b2f7eeee000 rw-p 00017000 08:05 156951 /lib64/libpthread-2.10.1.so 2b2f7eeee000-2b2f7eef2000 rw-p 00000000 00:00 0 2b2f7eef2000-2b2f7ef0a000 r-xp 00000000 08:05 173123 /usr/lib64/libslp.so.1.0.0 2b2f7ef0a000-2b2f7f109000 ---p 00018000 08:05 173123 /usr/lib64/libslp.so.1.0.0 2b2f7f109000-2b2f7f10a000 r--p 00017000 08:05 173123 /usr/lib64/libslp.so.1.0.0 2b2f7f10a000-2b2f7f10b000 rw-p 00018000 08:05 173123 /usr/lib64/libslp.so.1.0.0 2b2f7f10b000-2b2f7f124000 r-xp 00000000 08:05 185973 /usr/lib64/libsasl2.so.2.0.23 2b2f7f124000-2b2f7f323000 ---p 00019000 08:05 185973 /usr/lib64/libsasl2.so.2.0.23 2b2f7f323000-2b2f7f324000 r--p 00018000 08:05 185973 /usr/lib64/libsasl2.so.2.0.23 2b2f7f324000-2b2f7f325000 rw-p 00019000 08:05 185973 /usr/lib64/libsasl2.so.2.0.23./scripts/test003-search: l ine 93: 9220 Aborted (core dumped) $SLAPD -f $CONF1 -h $URI1 -d $LVL $TIMING > $LOG1 2>&1 ldapsearch failed (255)! ./scripts/test003-search: line 96: kill: (9220) - No such process >>>>> ./scripts/test003-search failed for bdb (exit 255) make[2]: *** [bdb-mod] Error 255 make[2]: Leaving directory `/usr/src/michael/openldap/HEAD/openldap/tests' make[1]: *** [test] Error 2 make[1]: Leaving directory `/usr/src/michael/openldap/HEAD/openldap/tests'

1 0

RE : (ITS#6367) syncprov ... changed by peer, ignored
by olivier.chirossel＠sfr.com 14 Nov '09

14 Nov '09

sorry for this the url is ok now Cdt, Olivier ________________________________________ De : Howard Chu [hyc(a)symas.com] Date d'envoi : vendredi 13 novembre 2009 23:33 =C0 : CHIROSSEL Olivier Cc : openldap-its(a)openldap.org Objet : Re: (ITS#6367) syncprov ... changed by peer, ignored olivier.chirossel(a)sfr.com wrote: > Full_Name: olivier chirossel > Version: 2.4.17 and 2.4.19 > OS: linux > URL: http://86.64.145.174:8080/ > Submission from: (NULL) (62.39.9.251) > > > in refreshend persist mode, the replication is incorrect for an entry whi= ch be > delete/add after master restart and before the reconnection of the slave. > 2) master set up > > on /etc/openldap tar xvf slapd_master.tar (get on the url ) The URL you provided always times out for me, so I've been unable to set up this test. -- -- Howard Chu CTO, 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#6377) test058-syncrepl-asymmetric failed for bdb (exit 3)
by hyc＠symas.com 14 Nov '09

14 Nov '09

hyc(a)symas.com wrote: > I'm seeing the same problem here. Still haven't identified the cause, looking... > Fixed. -- -- Howard Chu CTO, 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#6377) test058-syncrepl-asymmetric failed for bdb (exit 3)
by hyc＠symas.com 14 Nov '09

14 Nov '09

michael(a)stroeder.com wrote: > Full_Name: Michael Ströder > Version: HEAD synced now > OS: openSUSE Linux 11.2 (x86_64) > URL: > Submission from: (NULL) (84.163.61.118) > > > Stopping central master and site2 servers to test start with emtpy db... > Starting site2 master slapd on TCP/IP port 9013... > Using ldapsearch to check that site2 master slapd is running... > Starting site2 search slapd on TCP/IP port 9016... > Using ldapsearch to check that site2 search slapd is running... > Starting central master slapd on TCP/IP port 9011... > Using ldapsearch to check that central master slapd is running... > Using ldapsearch to check that site2 master received base... > Using ldapsearch to check that site2 search received base... > Waiting 1 seconds for syncrepl to receive changes... > Checking contextCSN after site2 servers repopulated... > Found 3 errors >>>>>> ./scripts/test058-syncrepl-asymmetric failed for bdb (exit 3) > make[2]: *** [bdb-mod] Error 3 > make[2]: Leaving directory `/usr/src/michael/openldap/HEAD/openldap/tests' > make[1]: *** [test] Error 2 > make[1]: Leaving directory `/usr/src/michael/openldap/HEAD/openldap/tests' > make: *** [test] Error 2 > > I'm seeing the same problem here. Still haven't identified the cause, looking... -- -- Howard Chu CTO, 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#6378) Slapadd core dump
by michael＠stroeder.com 14 Nov '09

14 Nov '09

acirulli(a)gmail.com wrote: > Full_Name: Andrea Cirulli > Version: 2.4.16 > OS: Solaris 9 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (62.77.56.182) > > > Problem with slapadd 2.4.16 using an ldif provided by slapcat 2.3.39 > > SLAPADD goes always in core dump on entry of ldif such the following: > > registeredAddress:: MTEzLjIxMS4yMjUuMTgxIAA= > > The base 64 value once converted is "113.211.225.181" + " " + '\0' Not sure whether slapcat 2.3.39 falsely added the NULL-byte at the end or whether it's part of your data. Could you please cross-check that with ldapsearch reading that particular entry? Nevertheless slapadd should not crash. Rather an error should be reported. But please try to reproduce the issue with a recent release (at least 2.4.19, preferrably CVS branch OPENLDAP_REL_ENG_2_4). Another option would be to provide sanitized test data to let others try to reproduce it. Ciao, Michael.

1 0

Re: (ITS#6361) Failed assertion in slapd when running on OpenWRT/glibc
by mike＠flyn.org 14 Nov '09

14 Nov '09

> Please provide stack traces for each of these assertions. In this case it > sounds like connection_closing() got called multiple times for the same > connection, after it had already been fully closed. A trace would help > confirm > that. This is a little odd: (gdb) run -d 255 Starting program: /usr/sbin/slapd -d 255 must compile with LDAP_DEBUG for debugging *** "CRASH" *** Program exited normally. (gdb) ba No stack. I have been running a script, while ldapsearch -x; do sleep 10; done, that eventually crashes slapd. But gdb provides little feedback, as noted above. >> One things to note is that, in addition to being on MIPS32, my platform >> has only 32MB of memory. I also have a swap file that is 64MB. > > In such an environment you won't have enough memory for more than 1 or 2 > server threads. Have you already configured this? I have just reconfigured slapd to use one thread and removed all indexes from the configuration. So far, I have not seen a crash. I am no using two clients to query slapd and have removed that sleep statements so that the server is continuously queried. I've been running this for about one hour and will report back if there are any negative results.

1 0

Re: (ITS#6365) Bad slapcat output when slapd running
by masarati＠aero.polimi.it 14 Nov '09

14 Nov '09

> Howard Chu wrote: >> Peter Mogensen wrote: >>> This is mirrormode. >>> There's no "provider" as such. However, there's one server which is >>> used >>> for application access and to minimize disk load on that server, the >>> plan was to take most backups from the other. >>> I can't see any difference between what you call "initializing" and >>> normal running state, except that the difference between server-1 and >>> server-2 is (somewhat) larger. >> >> If the problem is as Ando suggests, then it's because in the syncrepl >> Refresh >> phase it's receiving entries out-of-order from the provider. Ando is >> suggesting that the problem is caused when a child entry is replicated >> before >> its parent. Once the Refresh phase ends and it transitions to the >> Persist >> phase, all entries' parents will exist and so this particular condition >> will >> no longer occur. >> >> Of course, no one is saying for certain that this is the explanation, >> yet. > > It sounds reasonable to me :) > But unless you are not in any way allowed to - ever - make writes to > more than one server in a mirromode setup, this could (as I hear it) > potentially happen at any time. > The only reason I have to only make writes to one server is that I > currently (this will change) have an application which is dependant on > making writes and immediately reading back the entry. > > As I hear what you're saying is that any write to a server in a > mirrormode setup could invalidate a slapcat running on the other. > This would mean that you can never write to more that one server at all > and that's the only server you can slapcat while running. > That takes a lot of the "mirror" out of "mirrormode". Doesn't it? Based on my *very incomplete and possibly wrong* analysis, the problem would be automatically cured by using back-bdb. Also, fixing back-hdb *if it's broken at all* should be possible. p.

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs