vadius@vadius.ru wrote:

Full_Name: Vadim Prozorov Version: 2.4.38 OS: RHEL 6.3 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (91.210.4.1)

Hello,

I'm using slapd (2.4.38 release) built from sources on RHEL 6.3 64bit. Build params: LD_LIBRARY_PATH="/usr/lib:/usr/local/lib:/opt/local/BerkeleyDB.5.3/lib" LDFLAGS="-L/usr/local/lib -L/opt/local/BerkeleyDB.5.3/lib" CPPFLAGS="-I/usr/local/include -I/opt/local/BerkeleyDB.5.3/include" ./configure --prefix=/opt/local/OpenLDAP --enable-dynacl --enable-ldap —enable-overlays --disable-static --enable-dynamic

slapd works in master-master sync mode on host with big amount of RAM (whole DB can fit into RAM). One time host was hardly restarted. After restart slapd has started, but crash on any modification (at least, from ext application; may be form replica, haven't check yet). There is always the same crash stack:

Did you have dbnosync configured on this backend? Looks like garbage data got written to the freeDB.

(gdb) bt #0 mdb_xcursor_init1 (mc=0x7f3e1d6bbd40, node=0x7f3f99f46f82) at ./../../../libraries/liblmdb/mdb.c:6585 #1 0x000000000049f8eb in mdb_cursor_set (mc=0x7f3e1d6bbd40, key=0x7f3e1d6bbef0, data=0x0, op=MDB_SET_RANGE, exactp=<value optimized out>) at ./../../../libraries/liblmdb/mdb.c:5329 #2 0x00000000004a019f in mdb_cursor_get (mc=0x7f3e1d6bbd40, key=0x7f3e1d6bbef0, data=0x0, op=<value optimized out>) at ./../../../libraries/liblmdb/mdb.c:5529 #3 0x000000000049e0ed in mdb_page_alloc (mc=<value optimized out>, num=1, mp=0x7f3e1d6bbf68) at ./../../../libraries/liblmdb/mdb.c:1727 #4 0x000000000049e469 in mdb_page_touch (mc=0x7f3e1d6bc1d0) at ./../../../libraries/liblmdb/mdb.c:1911 #5 0x000000000049eb3a in mdb_page_search (mc=0x7f3e1d6bc1d0, key=0x0, flags=5) at ./../../../libraries/liblmdb/mdb.c:4830 #6 0x00000000004a7404 in mdb_freelist_save (txn=0x7f3e10115130) at ./../../../libraries/liblmdb/mdb.c:2522 #7 mdb_txn_commit (txn=0x7f3e10115130) at ./../../../libraries/liblmdb/mdb.c:2972 #8 0x00000000004a9e4e in mdb_modify (op=0x7f3e100028f0, rs=0x7f3e1d6bd910) at modify.c:664 #9 0x000000000043b4cb in fe_op_modify (op=0x7f3e100028f0, rs=0x7f3e1d6bd910) at modify.c:303 #10 0x000000000043bdf6 in do_modify (op=0x7f3e100028f0, rs=0x7f3e1d6bd910) at modify.c:177 #11 0x0000000000423c99 in connection_operation (ctx=0x7f3e1d6bda70, arg_v=0x7f3e100028f0) at connection.c:1155 #12 0x0000000000424475 in connection_read_thread (ctx=0x7f3e1d6bda70, argv=<value optimized out>) at connection.c:1291 #13 0x00007f3f9b6f04e8 in ldap_int_thread_pool_wrapper (xpool=0x16f36d0) at tpool.c:688 #14 0x0000003b6f2079d1 in start_thread () from /lib64/libpthread.so.0 #15 0x0000003b6eee8b6d in clone () from /lib64/libc.so.6

Crash can be reproduced by using data.mdb file on any host with the same slapd binaries. Also note contextCSN of DB became 'old' - it was actual on May 22 for both instances, when reset occured, but after start context CSN shows May 21 and 20.

Also mdb_stat utility crashes on attempt to show FreeDB data: $ mdb_stat -f ./data Freelist Status Tree depth: 3 Branch pages: 7 Leaf pages: 817 Overflow pages: 0 Entries: 16995 Segmentation fault (core dumped)