- openldap-bugs - openldap.org

(ITS#6381) connection_fake_init() from db_open() is unsafe
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 Originally the db_open() handlers only ran from slapd's main context, at startup time before threading was active. But with back-config, backends and overlays can be added at runtime and the db_open() handler then runs in a back-config operation thread. If a db_open handler calls connection_fake_init() using its current thread context, it will get the current sl_malloc memory context as well, and reset it to zero. Any sl_mallocs called up to that point will be forgotten and they'll be overwritten by subsequent calls in that thread. We never saw any problems with this prior to ITS#6380, because the prior mallocs tended to be higher up in the sl_malloc heap. So even though the heap was reset, the new mallocs didn't collide with the old ones. This is already fixed in HEAD: back-sql/init.c, back-monitor/init.c, and overlays/{dds.c, pcache.c, syncprov.c}

1 0

(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 14 Nov '09

14 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 14 Nov '09

14 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 14 Nov '09

14 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

(ITS#6378) Slapadd core dump
by acirulli＠gmail.com 14 Nov '09

14 Nov '09

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' The output of the slapadd in verbose mode is: Assertion failed: p == &normalized->bv_val[normalized->bv_len], file schema_init.c, line 2225 Abort (core dumped) 

1 0

Re: (ITS#6377) test058-syncrepl-asymmetric failed for bdb (exit 3)
by michael＠stroeder.com 14 Nov '09

14 Nov '09

See testrun/ http://www.stroeder.com/temp/openldap/openldap-its-6377-testrun.tar.gz

1 0

(ITS#6377) test058-syncrepl-asymmetric failed for bdb (exit 3)
by michael＠stroeder.com 14 Nov '09

14 Nov '09

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

1 0

Re: (ITS#6365) Bad slapcat output when slapd running
by apm＠mutex.dk 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? >> If I can't trust slapcat during this >> phase, how can I trust slapcat for backups? > > Does slapcat behave this way on the active server? I've taking that test setup down now to test other stuff, so I can't say 100%. /Peter

1 0

Re: (ITS#6365) Bad slapcat output when slapd running
by hyc＠symas.com 14 Nov '09

14 Nov '09

Peter Mogensen wrote: > Howard Chu wrote: >> apm(a)mutex.dk wrote: >>> Pierangelo Masarati wrote: >>>> You appear to be using back-hdb. >>> Yes. >>> >>>> My guess is that if this can fail, e.g. because entries are being >>>> sync'ed out of order, the DN does not get fixed. If this is the case (I >>>> couldn't inspect code deep enough to make sure), I'd expect that the DN >>>> get fixed anyway, though, because missing entries should exist as "glue" >>>> objects. >>> yes. But if you plan to use slapcat as a backup mechanism, then it's >>> still a problem. >> >> Sounds like a low priority issue at best. Taking backups of a replica while it >> is initializing is pointless, just take a backup of the provider instead. > > 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. > If I can't trust slapcat during this > phase, how can I trust slapcat for backups? Does slapcat behave this way on the active server? -- -- 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#6365) Bad slapcat output when slapd running
by apm＠mutex.dk 13 Nov '09

13 Nov '09

Howard Chu wrote: > apm(a)mutex.dk wrote: >> Pierangelo Masarati wrote: >>> You appear to be using back-hdb. >> Yes. >> >>> My guess is that if this can fail, e.g. because entries are being >>> sync'ed out of order, the DN does not get fixed. If this is the case (I >>> couldn't inspect code deep enough to make sure), I'd expect that the DN >>> get fixed anyway, though, because missing entries should exist as "glue" >>> objects. >> yes. But if you plan to use slapcat as a backup mechanism, then it's >> still a problem. > > Sounds like a low priority issue at best. Taking backups of a replica while it > is initializing is pointless, just take a backup of the provider instead. 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 I can't trust slapcat during this phase, how can I trust slapcat for backups? /Peter

1 0

(ITS#6376) memleak in 2.3
by mbackes＠symas.com 13 Nov '09

13 Nov '09

Full_Name: Matthew Backes Version: 2.3 only OS: any URL: Submission from: (NULL) (76.88.99.93) In 2.3, if you have a lot of fast writes such that syncprov_sendresp's op tmp memory is exhausted and it has resorted to malloc()s AND controls are asserted, the rs.sr_ctrls free at the end of the function leaks. To duplicate: Set up a master and a replica. Do mods like crazy with some control asserted, e.g. manageDSAIT. 2.4/head handle this differently so it isn't a problem there. Patch versus OPENLDAP_REL_ENG_2_3: RCS file: /repo/OpenLDAP/pkg/ldap/servers/slapd/overlays/syncprov.c,v retrieving revision 1.56.2.51 diff -u -u -r1.56.2.51 syncprov.c --- syncprov.c 9 Jul 2008 20:53:13 -0000 1.56.2.51 +++ syncprov.c 14 Nov 2009 04:14:26 -0000 @@ -803,6 +803,7 @@ } /* In case someone else freed it already? */ if ( rs.sr_ctrls ) { + op->o_tmpfree( rs.sr_ctrls[0]->ldctl_value.bv_val, op->o_tmpmemctx ); op->o_tmpfree( rs.sr_ctrls[0], op->o_tmpmemctx ); rs.sr_ctrls = NULL; } -- Matthew Backes Symas Corporation mbackes(a)symas.com

1 0

Re: ITS#6375
by jose.oliveira＠mailondemand.com.pt 13 Nov '09

13 Nov '09

This is a multi-part message in MIME format. --------------020401060209020404040703 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type"> </head> <body bgcolor="#ffffff" text="#000000"> Hi, I am sorry for the mistake and inconvenience. Thanks for pointing out right direction. Best regards, José Vicente Fonseca de Oliveira <img style="width: 125px; height: 108px;" alt="logo mailondemand" src="cid:part1.09010807.09040809@mailondemand.com.pt"> <a href="mailto:jose.oliveira@mailondemand.com.pt" target="_blank">jose.oliveira(a)mailondemand.com.pt</a> <a href="http://www.mailondemand.com.pt" target="_blank">http://www.mailondemand.com.pt</a> Av. Miguel Bombarda nº133, 7ºD 1050-164 Lisboa Tel: + 351 925440544 Skype + jvf_oliveira Pierangelo Masarati wrote: <blockquote cite="mid:4AFD95FF.8070209@aero.polimi.it" type="cite">The ITS is to track software bugs.  Please direct software usage questions to <a class="moz-txt-link-rfc2396E" href="mailto:openldap-solftware@openldap.org"><openldap-solftware(a)openldap.org></a> and software interoperation questions to <a class="moz-txt-link-rfc2396E" href="mailto:openldap-technical@openldap.org"><openldap-technical(a)openldap.org></a>. This ITS will be closed. p. _________________________ This email was transferred using an evaluation version of AXIGEN Mail Server. </blockquote> <div class="moz-signature">-- <meta content="text/html; charset=ISO-8859-1" http-equiv="content-type"> <title>JO_Letitwork</title> </div> </body> </html> _________________________ This email was transferred using an evaluation version of AXIGEN Mail Server. --------------020401060209020404040703 Content-Type: image/jpeg; name="modlogo_small.jpg" Content-Transfer-Encoding: base64 Content-ID: <part1.09010807.09040809(a)mailondemand.com.pt> Content-Disposition: inline; filename="modlogo_small.jpg" /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAUDBAQEAwUEBAQFBQUGBwwIBwcHBw8LCwkMEQ8S EhEPERETFhwXExQaFRERGCEYGh0dHx8fExciJCIeJBweHx7/2wBDAQUFBQcGBw4ICA4eFBEU Hh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh7/wAAR CABsAH0DASIAAhEBAxEB/8QAHAAAAAcBAQAAAAAAAAAAAAAAAAECAwQFBgcI/8QANxAAAQMD AwIDBgUDBAMAAAAAAQIDBAAFEQYSIRMxByJRFDJBYXGBI0KRobFSctEVM0PBFjRj/8QAFAEB AAAAAAAAAAAAAAAAAAAAAP/EABQRAQAAAAAAAAAAAAAAAAAAAAD/2gAMAwEAAhEDEQA/APZd ChQoBQos/Ki3UCqFNGQ1uKd6cjuM0sLSRkEGgVQot1FuGaBVCi3fKjBzQChQoUAoj3zR0KAg aOiPHNGDQCklXf5UqknuaCI/LUlvdHZLxzykKwRVLOmz1FSSh1tBOQNhyPuKsXsoeUUfA+Ye opaFhaeDgenpQZpTylKJWrzH1V/mnG3XRyhxz7Z/6rRqQ0oAKSk/Uc0yu3wlqyqOjJ+IGKCo TPlo49oV+v8AkVIRdpYI8yVj5p/xUpVojf8AG68j5b8j96Ycsqtx2voV/e3/AIoHU3p1PvsJ P0JH8in2r4yfeZWPoQarlWqWn3Etq/scI/Y005DmI9+M6oeuAqgvkXaGrupSfqmnm50VZwl5 B+9ZUjYcLBb/ALkKTS0HdwCFfRYV/NBrA6k9lJP3pQVmsXOnIhIUOOpgZyMYHrwavNJOqfsz T6lFRcJOSfnQXVFg0dCgFFjnvR0KCrleSQv9qZPHmT3/AJp25cSftUfefWgfbdCxkdx3HpTu 7jNRFA53oICv5pbLoWnnj1FBJCsjmnAeKjbh8KWFHsDQSEq+dGD8QTUZbqGk7nFgAdyTTXXe e/2ElCf61D+BQS33W205dIAPrUN1lMn3YzTaMZ3qTyfoKdYYSlW9eVr/AKlc0uY504j6z2Q2 on9KDkd5uBU44hBIAJH7mup6Oa6Om4CTnJaBP35riLznVd79zx9zXerS30bZGZ+KGkj9qCbQ oUKDO6p1tpbTExqHfbyxCkvR1yGmVJUpbjaFJSpSUpBKsFQyBzjJ7AkR7Z4g6Nud2YtVs1DC mS5DPWYQ0oqS6naFeVeNqiEqBKQcgHJFV9xs053xvtOpVRErtcXTkyGqQVIyh9yTGUlITndy htzkDHGCeQDz7SujtQWvSvhbAftiI79hny3rkhLzR6CXGJSQrKVYXlbqPdyfNk9jgNdfvEDq 3Z6NYNPzryiM6Y70lEhiOx1U+82hTq09RQwc7QQCCM8Go7niBDVpOTeo0Uofiy4sWRDnPBhT Snnm20kqAUCCHApJTlK+ACM5HFLlCjt3kQLzD07NkQrPKtJh3uYmN7I8t9biZ7O9KgsOJKcq RhQKQMjBxorBpK+XbwYjIhm2zphj2GCy3AmJcbW1b5TJddLitqSSEOqwOMJABUTQdh0lqQX6 4akiGH7ObJeF2zd1N3W2sMu9TGBt/wB7G3n3c55wE3DXGkrfqAWOZfobNyK0NlpW7CFr9xCl 42oUrIwlRBORiq3w/tNxtV31rInx+i3c9RuToZ3pV1GTFjNhXBO3zNrGDg8dsEVi77pfVy7f q3SMTTzUuLqK6Klt3tU1pLcZDnT3dRsnqlxvYdm1KgcJ5FB0O7+IuibPdJNqumo4cSbFcbak tOBX4ClpSpG8gYQCFpwokDnGc1orjLTFhuynHW2GWUlx111QSlCAMlRJ4AA5zXLL5o69SbZ4 xstW1Lr2pYiWrSVOtgylJtaGBklXkw6FDz7fXtzWp1vp6fqLwln6YZcaanybWlhPWVlHUCU+ VRGfKSnaSM8E96CNpzxF07ftcw9P2SS1c0yLXIuLkvepBaDbjKEp6akjKVB0kLBx5eM5yNBp /W2k79dja7NfIsyYEqWltG4dRKThSmyQA4ASMlBIFc8cs+r9Ua7RdZ+lHNMw/wDxWdaVPLnx 33EvvOMFOA0o+QBCik9+DkJyAS8K9I3a33fTov1i1GhyxMltubIv7D8FKun0yWWknqYUM8KS nHzxQbWD4reHk1tLkTVlvdQtj2hsgL/FRlI8mU+dWVJBSnKgSBinNR6406jw9c1JDuCZ8KYh TEIxUla5Lp3J6aE99wKVZBxt2qzjBrC6F0Lf7ZZvBiNOs7bTmmESv9WT1mlezKXDdQkjCjvJ dUnlG7nk8DNU2qrFetM6Tud0ucZyNETqW9v72lJdMePNWroSsIJwBkZHdIcJIGDQZ+26s2XS Gi72WVbozshLXtC32XUoO5I/ECFko5IBJGBkZxXoG7eI2h7HOetd11DEizIgbElpSVEshaQU qWQCEpI/McD51420rpw3K+afs9vZ0tDcetki1SZEW4BxcjqJQDI2pRlSsJWoZ5yeSBivSj2m ru8fFFSLehZv8BqPblF1vMgpiKbKTk+UbzjzYHOe3NB0TUWttKaemxIV5vkSHIloLrSFEn8M EAuKwDsbyR51YT86Lwz1MdZ6AseqzB9g/wBVhok+zdXqdLcM7d2Bn64Fc8tdk1fp3US7lE0u 3qFF401b7W8lyay37A/HS6FJc3nzMK62SW96spPlORWx8D7Jc9N+EOlrDeo3stxgW1piSz1E r2LSORuSSk/UEig0cg5SaqZ5wDjvVxIAKTVZKa3ZyKDB6otMW6Ae3Q48nZ7nWaC9v0yOKz64 06CoKhSXmMDACVHH6dq6LNiBWeKqZlvBHYUGaias1BCwmQGpaB/WMH9RV3A1/BXhM6K9HV8S BuFQ5NrB7Jqsk2gEny0HQbdf7RPA9mnsLUfylWD+hq0QoiuMP2jBKgnB+XFORJd9t3/qT5CQ PyqVuH6Gg7MlfPejJwdzf3Fcyha6vDGBNiMygO5RlBP/AFWgt+u7NIUEyA9DX/8AROR+ooNg leeQeKzviY9s0m8M4K1oT+9WMS4QpWFw5TT2e4SofxWb8V5ATp9htIV+LIAGB6A0HO9MoiwL 63Ihw4zasnqltsJJ+pA5rsFonIkISoHFcx09bHdyVrB3HGeK3tmjrbSO9Bsoi8gYqe2Vbe9U 9vztHNW7OdnagQ63x2qI80DxirMjNNONjvQUz0cEcioL0UHvV+40DTDkfPwFBm3oXHaojsAH 4VqnIwNMKij0oMg9bQfy/tUR21A/l/atouIk00qCPSgw7tnTn3f2plVhSr/jz9q3nsA9KUiA PSgwcXTQDgUjc2fVPBrRMWcOMIalLXICFbkhw5wa0TMNKfhzUhEYA9qCni2uO37rYFWkaClP apTbAB7CpTLWKBMeOE9hUwBIGKShO0c0a/hmgXREZo6FAkoBpBbBp2kUDSmvjikKaHfFScmj wKCF0BntRFgH4VO2ihtFBA9nHpSkx0/Gpu0UNooIyY4+ApYZA+FOng4FDJ9aBAbA+FObR8BS aWKBOPnSXCvjakH6mnD2pIoP/9k= --------------020401060209020404040703--

1 0

Re: (ITS#6368) Bug in deleting entry in MirrorMode
by hyc＠symas.com 13 Nov '09

13 Nov '09

pitpalme(a)gmail.com wrote: > masarati(a)aero.polimi.it wrote: > >> pitpalme(a)gmail.com wrote: >> >>> I do see attributes reflecting state after "modify" (which changes >>> "sn" attribute). >>> Where exactly should I expect to see a note about "glue state"? >>> Is output from "-d Any" helpful to figure what's going on (or wrong)? >> >> My understanding of your previous message was that you got a positive >> result from delete, but an "Already exists" from a subsequent add. > > That=92s korrekt. > >> I inferred that you checked about the existence of the object and =20 >> you got >> a negative result. > > In my current test scenario I do not check. > I assume a non-error on =84delete=93 in fact =84deletes=93, so I just = > check if =20 > response > code success (in Perl: '$res->code =3D=3D Net::LDAP::LDAP_SUCCESS=91). > >> Apparently, my guess was wrong. In that case, you probably hit >> ITS#6097 <http://www.openldap.org/its?findid=3D6097>. > > *hmmm* Good idea, thanks. > But after reading ITS description I don=92t think it=92s what troubles = > me. > We don=92t actually neither have =84multi master mode=93, but =84mirror = > mode=93 =20 > and writes are done only on exactly one server, so there should not be =20= > > a problem with second server producing a concurrent write/modify. > I=92d expect the delete to be correctly propagated, but I can=92t check = > it =20 > is is, simply because I have to little knowledge to read debug log =20 > correctly. > =97 Paste the debug log somewhere we can see it then. Might as well use debug level -1 while executing this sequence. And provide the debug output from both servers. -- -- 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#6361) Failed assertion in slapd when running on OpenWRT/glibc
by hyc＠symas.com 13 Nov '09

13 Nov '09

mike(a)flyn.org wrote: > Yes, I have just been able to recreate this in 2.4.19. The line in > daemon.c at which the assertion occurs in this version is 994. > > I have also seen: > > ldap_write: want=22 error=Broken pipe > ... > slapd: connection.c:786: connection_closing: Assertion 'c->c_struct_state > == SLAP_C_USED' failed 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. > 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? -- -- 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#6367) syncprov ... changed by peer, ignored
by hyc＠symas.com 13 Nov '09

13 Nov '09

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 which 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#6365) Bad slapcat output when slapd running
by hyc＠symas.com 13 Nov '09

13 Nov '09

apm(a)mutex.dk wrote: > Pierangelo Masarati wrote: >> You appear to be using back-hdb. > > Yes. > >> My guess is that if this can fail, e.g. because entries are being >> sync'ed out of order, the DN does not get fixed. If this is the case (I >> couldn't inspect code deep enough to make sure), I'd expect that the DN >> get fixed anyway, though, because missing entries should exist as "glue" >> objects. > > yes. But if you plan to use slapcat as a backup mechanism, then it's > still a problem. Sounds like a low priority issue at best. Taking backups of a replica while it is initializing is pointless, just take a backup of the provider instead. -- -- 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#6365) Bad slapcat output when slapd running
by apm＠mutex.dk 13 Nov '09

13 Nov '09

Pierangelo Masarati wrote: > You appear to be using back-hdb. Yes. > My guess is that if this can fail, e.g. because entries are being > sync'ed out of order, the DN does not get fixed. If this is the case (I > couldn't inspect code deep enough to make sure), I'd expect that the DN > get fixed anyway, though, because missing entries should exist as "glue" > objects. yes. But if you plan to use slapcat as a backup mechanism, then it's still a problem. /Peter

1 0

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

13 Nov '09

apm(a)mutex.dk wrote: > Full_Name: Peter Mogensen > Version: 2.4.19 > OS: Debian Lenny > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (95.166.36.16) > > > Using openldap 2.4.17 and 2.4.19 linked with libdb4.6 and libdb4.8 in a > mirrormode setup: > > * Load the database with slapadd on server-1, start server-1 > The LDIF being loaded is generated with slapcat from a slapd 2.3.30-5+etch2 > Running on Debian Etch. I have no reason to suspect that it is not loaded > correctly into server1 > > * Start server-2 and monitor the progress of replication with slapcat, for > example: > > # for ((I=1;I<=20;I++)); do slapcat > out-$I; done > > * Look at the output: > > # for ((I=1;I<=20;I++)); do wc -l out-$I; done > > I would expect the generated files to be strictly increasing in size. > However, some times there's a file which is smaller than the previous. > In it I see LDIF entries like this: > > dn: > objectClass: top > objectClass: NamedObject > objectClass: simpleSecurityObject > uid: rieke > userPassword:: e1NBU0x..... > structuralObjectClass: NamedObject > entryUUID: e46b680e-e5f5-102b-93c9-79162adc1d46 > creatorsName: dc=admin,dc=example,dc=com > createTimestamp: 20070823185333Z > entryCSN: 20070823185333.000000Z#000002#000#000000 > modifiersName: dc=admin,dc=example,dc=com > modifyTimestamp: 20070823185333Z > > ... with an empty DN line. You appear to be using back-hdb. I note that in bdb_tool_entry_get() there is code specific to back-hdb that tries to lookup the parent of the current entry and, if found, "fixes" its DN. My guess is that if this can fail, e.g. because entries are being sync'ed out of order, the DN does not get fixed. If this is the case (I couldn't inspect code deep enough to make sure), I'd expect that the DN get fixed anyway, though, because missing entries should exist as "glue" objects. I apologize for the rather incomplete analysis, I can't dig further right now. I hope this provides some hint to others, unless completely wrong. p.

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs