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.
