ryan@openldap.org wrote:

On Tue, Nov 17, 2015 at 09:13:46AM +0000, BÖSCH Christian wrote:

...

The slapcat output is attached below.

Thanks for that. Now I did reproduce the bug, in current git master and also in RE24.

This particular problem can be fixed by setting op->o_do_not_cache in dds_count. Not sure what's needed for a more general solution.

The backtrace (line numbers from master) is:

Program received signal SIGSEGV, Segmentation fault. 0x00000000004d9de3 in mdb_txn_begin (env=0x0, parent=0x0, flags=0, ret=0x7fffffe6c750) at ./../../../libraries/liblmdb/mdb.c:2760 2760 flags |= env->me_flags & MDB_WRITEMAP; (gdb) bt #0 0x00000000004d9de3 in mdb_txn_begin (env=0x0, parent=0x0, flags=0, ret=0x7fffffe6c750) at ./../../../libraries/liblmdb/mdb.c:2760 #1 0x0000000000534d82 in mdb_opinfo_get (op=0x7fffffe6ca20, mdb=0x7ffff6eb0010, rdonly=0, moip=0x7fffffe6c738) at id2entry.c:472 #2 0x00000000005256d9 in mdb_add (op=0x7fffffe6ca20, rs=0x7fffffe6c9b0) at add.c:68 #3 0x0000000000557376 in accesslog_response (op=0x7fffffffd660, rs=0x7fffffffd5c0) at accesslog.c:1867 #4 0x00000000004ba728 in over_back_response (op=0x7fffffffd660, rs=0x7fffffffd5c0) at backover.c:245 #5 0x0000000000441997 in slap_response_play (op=0x7fffffffd660, rs=0x7fffffffd5c0) at result.c:551 #6 0x0000000000441bba in send_ldap_response (op=0x7fffffffd660, rs=0x7fffffffd5c0) at result.c:626 #7 0x0000000000442ad1 in slap_send_ldap_result (op=0x7fffffffd660, rs=0x7fffffffd5c0) at result.c:905 #8 0x00000000004f358d in mdb_search (op=0x7fffffffd660, rs=0x7fffffffd5c0) at search.c:1186 #9 0x00000000004bb665 in overlay_op_walk (op=0x7fffffffd660, rs=0x7fffffffd5c0, which=op_search, oi=0x9e4f30, on=0x0) at backover.c:696 #10 0x00000000004bb889 in over_op_func (op=0x7fffffffd660, rs=0x7fffffffd5c0, which=op_search) at backover.c:749 #11 0x00000000004bb969 in over_op_search (op=0x7fffffffd660, rs=0x7fffffffd5c0) at backover.c:776 #12 0x000000000055d817 in dds_count (ctx=0x895e40 <ldap_int_main_thrctx>, be=0x7fffffffdd90) at dds.c:1670 #13 0x000000000055daaf in dds_db_open (be=0x7fffffffdd90, cr=0x7fffffffdfa0) at dds.c:1737 #14 0x00000000004ba3b2 in over_db_open (be=0x9e4460, cr=0x7fffffffdfa0) at backover.c:157 #15 0x000000000043c6ee in backend_startup_one (be=0x9e4460, cr=0x7fffffffdfa0) at backend.c:224 #16 0x000000000043cc38 in backend_startup (be=0x9e4460) at backend.c:330 #17 0x0000000000468fcf in slap_startup (be=0x0) at init.c:220 #18 0x0000000000405e86 in main (argc=8, argv=0x7fffffffe308) at main.c:997

At first glance it looks like another problem related to ITS#8133, where dds triggers calls into another module (this time, accesslog) before it has actually initialized.