Full_Name: Pierangelo Masarati Version: re24 OS: Linux x86 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (81.72.89.40) Submitted by: ando I had a strange core dump while testing re24 (test039). I'm reporting it in order to be able to investigate it further later. Backtrace follows: (gdb) bt #0 0x00800402 in __kernel_vsyscall () #1 0x00c9ad20 in raise () from /lib/libc.so.6 #2 0x00c9c631 in abort () from /lib/libc.so.6 #3 0x00c9416b in __assert_fail () from /lib/libc.so.6 #4 0x0817c7e5 in ldap_back_conn_delete (li=0x8a9ef30, lc=0x8b55df8) at bind.c:157 #5 0x0817d20a in ldap_back_freeconn (li=0x8a9ef30, lc=0x8b55df8, dolock=0) at bind.c:467 #6 0x0817e8cf in ldap_back_release_conn_lock (li=0x8a9ef30, lcp=0xb4376d10, dolock=1) at bind.c:1144 #7 0x0817cf12 in ldap_back_bind (op=0x8b973e0, rs=0xb4377128) at bind.c:355 #8 0x080fac38 in overlay_op_walk (op=0x8b973e0, rs=0xb4377128, which=op_bind, oi=0x8a82d78, on=0x0) at backover.c:667 #9 0x080faded in over_op_func (op=0x8b973e0, rs=0xb4377128, which=op_bind) at backover.c:719 #10 0x080fae2d in over_op_bind (op=0x8b973e0, rs=0xb4377128) at backover.c:729 #11 0x080a8311 in fe_op_bind (op=0x8b973e0, rs=0xb4377128) at bind.c:383 #12 0x080fac38 in overlay_op_walk (op=0x8b973e0, rs=0xb4377128, which=op_bind, oi=0x8a85090, on=0x0) at backover.c:667 #13 0x080faded in over_op_func (op=0x8b973e0, rs=0xb4377128, which=op_bind) at backover.c:719 #14 0x080fae2d in over_op_bind (op=0x8b973e0, rs=0xb4377128) at backover.c:729 #15 0x080a7aa7 in do_bind (op=0x8b973e0, rs=0xb4377128) at bind.c:205 #16 0x08083c40 in connection_operation (ctx=0xb4377210, arg_v=0x8b973e0) at connection.c:1084 #17 0x0808411a in connection_read_thread (ctx=0xb4377210, argv=0x1f) at connection.c:1210 #18 0x08207d35 in ldap_int_thread_pool_wrapper (xpool=0x8a595b8) at tpool.c:663 #19 0x00deb46b in start_thread () from /lib/libpthread.so.0 #20 0x00d42dbe in clone () from /lib/libc.so.6 (gdb) f 4 #4 0x0817c7e5 in ldap_back_conn_delete (li=0x8a9ef30, lc=0x8b55df8) at bind.c:157 157 assert( !LDAP_BACK_CONN_TAINTED( lc ) ); (gdb) p *lc $1 = {lc_conn = 0xb7e91ba0, lc_ld = 0x8b79160, lc_cred = {bv_len = 0, bv_val = 0x0}, lc_bound_ndn = {bv_len = 68, bv_val = 0x8b2dce8 "cn=james a jones 1,ou=alumni association,ou=people,dc=example,dc=com"}, lc_local_ndn = {bv_len = 68, bv_val = 0x8b37e28 "cn=james a jones 1,ou=alumni association,ou=people,dc=example,dc=com"}, lc_lcflags = 289, lc_refcnt = 0, lc_flags = 4096, lc_create_time = 0, lc_time = 0, lc_q = {tqe_next = 0x0, tqe_prev = 0x0}} (gdb) p /x lc->lc_lcflags $2 = 0x121 The connection is simultaneously cached (0x100) and tainted (0x20); this triggers an assert. Note that (gdb) f 7 #7 0x0817cf12 in ldap_back_bind (op=0x8b973e0, rs=0xb4377128) at bind.c:355 355 ldap_back_release_conn( li, lc ); (gdb) p retrying $4 = LDAP_BACK_RETRYING so apparently no one had a chance to taint the connection (from within this thread). Probably, the assert is too tight. Either tainting and uncaching should occur simultaneously, or the assert should just be relaxed. p.