[email protected] 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. > > > > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
