Re: (ITS#7628) back-mdb bug with test064-constraint

[hyc@symas.com]

h.b.furuseth@usit.uio.no wrote:
> Full_Name: Hallvard B Furuseth
> Version: master, 7c6b599de6d7c0e10aa8bf6920ca07d94605e8c2
> OS: Linux amd64
> URL:
> Submission from: (NULL) (129.240.203.186)
> Submitted by: hallvard
>
>
> id2entry.c:mdb_opinfo_get() renews a txn which is in use. It gets
> EINVAL, which it does not catch. Caught by this patch and test064:

Fixed now in master. I've left this assert in place as well, it obviously 
Should Never Happen.
>
> index 84de09d..a247974 100644
> --- a/servers/slapd/back-mdb/id2entry.c
> +++ b/servers/slapd/back-mdb/id2entry.c
> @@ -507,3 +507,4 @@ mdb_opinfo_get( Operation *op, struct mdb_info *mdb, int
> rdonly, mdb_op_info **m
>   	if ( renew ) {
> -		mdb_txn_renew( moi->moi_txn );
> +		rc = mdb_txn_renew( moi->moi_txn );
> +		assert(rc == MDB_SUCCESS);
>   	}
>
> Core file in ada:/home/hallvard/openldap.g/tests/core.
>
>
>
> #2  0x00007ff6a1609301 in *__GI___assert_fail (assertion=0x601014 "rc == 0",
> file=<value optimized out>, line=509,
>      function=0x601141 "mdb_opinfo_get") at assert.c:81
> #3  0x0000000000515db1 in mdb_opinfo_get (op=0x7ff69e411130, mdb=0x7ff6a2a02010,
> rdonly=1, moip=0x7ff69e280d08)
>      at id2entry.c:509
> #4  0x00000000004f2bed in mdb_search (op=0x7ff69e411130, rs=0x7ff69e4112a0) at
> search.c:343
> #5  0x00000000004c4f08 in overlay_op_walk (op=0x7ff69e411130, rs=0x7ff69e4112a0,
> which=op_search, oi=0x15b30e0, on=0x0)
>      at backover.c:691
> #6  0x00000000004c511f in over_op_func (op=0x7ff69e411130, rs=0x7ff69e4112a0,
> which=op_search) at backover.c:743
> #7  0x00000000004c5207 in over_op_search (op=0x7ff69e411130, rs=0x7ff69e4112a0)
> at backover.c:770
> #8  0x000000000052a197 in constraint_violation (c=0x15dc620, bv=0x1af6f90,
> op=0x17c8cf0) at constraint.c:666
> #9  0x000000000052a82a in constraint_add (op=0x17c8cf0, rs=0x7ff69e411a60) at
> constraint.c:812
> #10 0x00000000004c4e69 in overlay_op_walk (op=0x17c8cf0, rs=0x7ff69e411a60,
> which=op_add, oi=0x15b30e0, on=0x15b32c0)
>      at backover.c:681
> #11 0x00000000004c511f in over_op_func (op=0x17c8cf0, rs=0x7ff69e411a60,
> which=op_add) at backover.c:743
> #12 0x00000000004c52af in over_op_add (op=0x17c8cf0, rs=0x7ff69e411a60) at
> backover.c:794
> #13 0x000000000043aa44 in fe_op_add (op=0x17c8cf0, rs=0x7ff69e411a60) at
> add.c:334
> #14 0x000000000043a341 in do_add (op=0x17c8cf0, rs=0x7ff69e411a60) at add.c:194
> #15 0x0000000000430da3 in connection_operation (ctx=0x7ff69e411b90,
> arg_v=0x17c8cf0) at connection.c:1155
> #16 0x0000000000431344 in connection_read_thread (ctx=0x7ff69e411b90, argv=0xb)
> at connection.c:1291
> #17 0x00000000005953c5 in ldap_int_thread_pool_wrapper (xpool=0x1543920) at
> tpool.c:688
>
>
> (gdb) frame 3
> #3  0x0000000000515db1 in mdb_opinfo_get (op=0x7ff69e411130, mdb=0x7ff6a2a02010,
> rdonly=1, moip=0x7ff69e280d08)
>      at id2entry.c:509
> 509			assert(rc == MDB_SUCCESS);
> (gdb) info locals
> rc = 22
> renew = 1
> data = 0x1af36b0
> ctx = 0x7ff69e411b90
> moi = 0x7ff69e280d10
> oex = 0x0
> __PRETTY_FUNCTION__ = "mdb_opinfo_get"
> (gdb) p *moi
> $1 = {moi_oe = {oe_next = {sle_next = 0x7ff69e411850}, oe_key = 0x7ff6a2a02010},
> moi_txn = 0x1af36b0, moi_ref = 0,
>    moi_flag = 1 '\001'}
> (gdb) p *moi->moi_txn
> $2 = {mt_parent = 0x0, mt_child = 0x0, mt_next_pgno = 31, mt_txnid = 51, mt_env
> = 0x17c0920, mt_free_pgs = 0x0,
>    mt_u = {dirty_list = 0x7ff6a2bd5080, reader = 0x7ff6a2bd5080}, mt_dbxs =
> 0x17baa80, mt_dbs = 0x1af3718,
>    mt_cursors = 0x0, mt_dbflags = 0x1af4f78 "\b\b\n\b\b\b\n\n\n\n\n", mt_numdbs =
> 11, mt_flags = 1, mt_dirty_room = 0,
>    mt_toggle = 1}
>
> The EINVAL was returned because mt_dbxs != NULL.
>
>


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