openldap-bugs November 2009

openldap-bugs@openldap.org

40 participants
183 discussions

Re: (ITS#6325) test054: test failed - producer and consumer databases differ
by hyc＠symas.com 15 Nov '09

15 Nov '09

michael(a)stroeder.com wrote: > Download testrun/ here: > > http://www.stroeder.com/temp/openldap/its6325-test054-testrun.tar.gz It's certainly a mystery. The *.flt shows that an entry is missing on the slave. The slapd.1.log shows that the provider sent the entry. The slapd.4.log shows that the consumer received the entry and ignored it. (See slapd.4.log line 3307-3313. Compare with the previously received entry, lines 3161-3169.) The most puzzling part is that every code path in the consumer that rejects an entry logs an error message, and there is no error message in the log file. Without any means to reproduce this there's not much we can do. Setting a higher debug level might be useful, but any error messages in this path should have shown up regardless. -- -- 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: RE : (ITS#6367) syncprov ... changed by peer, ignored
by hyc＠symas.com 15 Nov '09

15 Nov '09

CHIROSSEL Olivier wrote: > sorry for this > > the url is ok now Thanks. This is now fixed in HEAD. > > Cdt, > > Olivier > ________________________________________ > De : Howard Chu [hyc(a)symas.com] > Date d'envoi : vendredi 13 novembre 2009 23:33 > À : 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 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#6362) slapd 2.4.19 Segmentation fault under load
by hyc＠symas.com 15 Nov '09

15 Nov '09

alexs(a)ulgsm.ru wrote: > Full_Name: Aleksey > Version: 2.4.19 > OS: Freebsd7.2 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (93.93.136.26) > > > Openldap 2.4.19 installed from freebsd ports. All configs in defauls > Freebsd 7.2 amd64 > Slapd built with the "-g" flag and install with the make install STRIP="" > > Used backends db46-4.6.21.4, db47-4.7.25.4 latest from freebsd ports. > In slapd config added using hdb as backend and indexes. > > Testing database consist of 1000 users accounts with minimum attributes. > > On stress test load slapd Segmentation fault in 10-30 sec. Looks like you've had a stack overrun. The "be" parameter should be the same in your frame 0 and frame 1. > #gdb /usr/local/libexec/slapd > (gdb) run -d 0 > Starting program: /usr/local/libexec/slapd -d 0 > [New LWP 100311] > [New Thread 0x801a020b0 (LWP 100311)] > [New Thread 0x801a02880 (LWP 100073)] > [New Thread 0x8034040b0 (LWP 100076)] > [New Thread 0x803404240 (LWP 100077)] > [New Thread 0x8034043d0 (LWP 100078)] > [New Thread 0x803404560 (LWP 100116)] > > Program received signal SIGSEGV, Segmentation fault. > [Switching to Thread 0x803404560 (LWP 100116)] > 0x0000000802d5aa4b in hdb_idl_fetch_key (be=Error accessing memory address > 0x7ffffd9f9f38: Bad s. > ) at idl.c:511 > 511 { > (gdb) > (gdb) > (gdb) where > #0 0x0000000802d5aa4b in hdb_idl_fetch_key (be=Error accessing memory > address 0x7ffffd9f9f38: dress. > ) at idl.c:511 > #1 0x0000000802d50dc5 in hdb_key_read (be=0x801a853d0, db=0x803519800, > txn=0x80352b040, k=0x8069005 > 70, ids=0x806a00000, saved_cursor=0x0, get_flag=0) at key.c:50 > #2 0x0000000802d5363c in equality_candidates (op=0x803521000, rtxn=0x80352b040, > ava=0x7ffffda7a4f0, > ids=0x806c00000, tmp=0x806a00000) at filterindex.c:788 > #3 0x0000000802d51d10 in hdb_filter_candidates (op=0x803521000, > rtxn=0x80352b040, f=0x7ffffda7a550, > ids=0x806c00000, tmp=0x806a00000, stack=0x806d00000) at filterindex.c:154 > #4 0x0000000802d5297f in list_candidates (op=0x803521000, rtxn=0x80352b040, > flist=0x7ffffda7a5 f > type=161, ids=0x806b00000, tmp=0x806a00000, save=0x806c00000) at > filterindex.c:581 > #5 0x0000000802d5229c in hdb_filter_candidates (op=0x803521000, > rtxn=0x80352b040, f=0x7ffffda7a530, > ids=0x806b00000, tmp=0x806a00000, stack=0x806c00000) at filterindex.c:204 > #6 0x0000000802d5297f in list_candidates (op=0x803521000, rtxn=0x80352b040, > flist=0x7ffffda7a5 f > type=160, ids=0x7ffffdafa760, tmp=0x806a00000, save=0x806b00000) at > filterindex.c:581 > #7 0x0000000802d521e4 in hdb_filter_candidates (op=0x803521000, > rtxn=0x80352b040, f=0x7ffffda7a570, > ids=0x7ffffdafa760, tmp=0x806a00000, stack=0x806b00000) at filterindex.c: > #8 0x0000000802d4dca9 in search_candidates (op=0x803521000, rs=0x7ffffdbfab30, > e=0x7ffffda7a71 tx > n=0x80352b040, ids=0x7ffffdafa760, scopes=0x7ffffda7a760) at search.c:1206 > #9 0x0000000802d4befa in hdb_search (op=0x803521000, rs=0x7ffffdbfab30) at > search.c:586 > #10 0x0000000000439bb5 in fe_op_search (op=0x803521000, rs=0x7ffffdbfab30) at > search.c:366 > #11 0x0000000000439520 in do_search (op=0x803521000, rs=0x7ffffdbfab30) at > search.c:217 > #12 0x000000000043613d in connection_operation (ctx=0x7ffffdbfac70, > arg_v=0x803521000) at connection > .c:1123 > #13 0x00000000004366d9 in connection_read_thread (ctx=0x7ffffdbfac70, argv=0x12) > at connection.c:125 > 9 > #14 0x0000000800797052 in ldap_int_thread_pool_wrapper () from > /usr/local/lib/libldap_r-2.4.so. > #15 0x000000080164b4d1 in pthread_getprio () from /lib/libthr.so.3 > #16 0x0000000000000000 in ?? () > Error accessing memory address 0x7ffffdbfb000: Bad address. -- -- 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

(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

← Newer
1
...
9
10
11
12
13
14
15
...
19
Older →

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 November 2009