Re: (ITS#8307) startup failed with DDS enabled

[hyc@symas.com]

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.
>
>
>
>


-- 
   -- Howard Chu
   CTO, Symas Corp.           http://www.symas.com
   Director, Highland Sun     http://highlandsun.com/hyc/
   Chief Architect, OpenLDAP  http://www.openldap.org/project/