Re: RE : (ITS#6367) syncprov ... changed by peer, ignored
by hyc＠symas.com
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/
12 years, 7 months
Re: (ITS#6362) slapd 2.4.19 Segmentation fault under load
by hyc＠symas.com
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/
12 years, 7 months
(ITS#6381) connection_fake_init() from db_open() is unsafe
by hyc＠OpenLDAP.org
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}
12 years, 7 months
(ITS#6380) slap_sl_free is too lazy
by hyc＠OpenLDAP.org
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.
12 years, 7 months
Re: (ITS#6377) test058-syncrepl-asymmetric failed for bdb (exit 3)
by michael＠stroeder.com
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'
12 years, 7 months
RE : (ITS#6367) syncprov ... changed by peer, ignored
by olivier.chirossel＠sfr.com
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/
12 years, 7 months