(ITS#4821) test043 cores; apparently incorrect resource usage

[ando@sys-net.it]

Full_Name: Pierangelo Masarati
Version: HEAD
OS: Linux 2.6 (CentOS 4.4)
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (87.28.220.33)
Submitted by: ando


test43 results in a couple of core dumps.  The first occurs to the producer. 
Valgrind is showing

==1654== Invalid read of size 4
==1654==    at 0x8148BC3: bdb_locker_id_free (cache.c:1360)
==1654==    by 0x81E5F7A: ldap_pvt_thread_pool_context_reset (tpool.c:903)
==1654==    by 0x80B48EF: slap_destroy (init.c:275)
==1654==    by 0x8062E2B: main (main.c:954)
==1654==  Address 0x4ED36A0 is 520 bytes inside a block of size 680 free'd
==1654==    at 0x4004EFA: free (vg_replace_malloc.c:235)
==1654==    by 0x8217E09: ber_memfree_x (memory.c:149)
==1654==    by 0x8217E6D: ber_memfree (memory.c:162)
==1654==    by 0x58E09E: __os_free (in /lib/tls/i686/libdb-4.2.so)
==1654==    by 0x56D6E6: __dbenv_close (in /lib/tls/i686/libdb-4.2.so)
==1654==    by 0x56D816: __dbenv_close_pp (in /lib/tls/i686/libdb-4.2.so)
==1654==    by 0x80FE3D8: bdb_db_close (init.c:512)
==1654==    by 0x80F1430: over_db_close (backover.c:195)
==1654==    by 0x808D7A4: backend_shutdown (backend.c:352)
==1654==    by 0x80B4846: slap_shutdown (init.c:258)
==1654==    by 0x8062E0A: main (main.c:947)

bdb_locker_id_free() is passed to ldap_pvt_thread_pool_setkey() as cleanup
function, but apparently the keys are cleaned up __after__ the key (the db env)
has already been destroyed (in bdb_do_close()).

The second core occurs again in the producer, since the test doesn't realize it
cored and thus tries to restart it, according to the test pattern.  Valgrind in
this case only reports

slapd: schema_check.c:87: entry_schema_check: Assertion `a->a_vals[0].bv_val !=
((void *)0)' failed.

If the same problem is reproduced without valgrind (the vgcore appears to be
screwed), a NULL attribute seems to be left 'round:

(gdb) bt
#0  0x003957a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2
#1  0x003d57a5 in raise () from /lib/tls/libc.so.6
#2  0x003d7209 in abort () from /lib/tls/libc.so.6
#3  0x003ced91 in __assert_fail () from /lib/tls/libc.so.6
#4  0x080bc142 in entry_schema_check (op=0xb6f10760, e=0x8a606dc, oldattrs=0x0,
manage=0, add_soc=1, text=0xb6f10738, 
    textbuf=0xb6f1040c "��@", textlen=256) at schema_check.c:87
#5  0x08144565 in bdb_add (op=0xb6f10760, rs=0xb6f10724) at add.c:97
#6  0x080f1c30 in overlay_op_walk (op=0xb6f10760, rs=0xb6f10724, which=op_add,
oi=0x89e5968, on=0x0) at backover.c:507
#7  0x080f1de5 in over_op_func (op=0xb6f10760, rs=0xb6f10724, which=op_add) at
backover.c:559
#8  0x080f1ef1 in over_op_add (op=0xb6f10760, rs=0xb6f10724) at backover.c:605
#9  0x081a308d in accesslog_response (op=0x8a84160, rs=0xb6f111c8) at
accesslog.c:1279
#10 0x080f1560 in over_back_response (op=0x8a84160, rs=0xb6f111c8) at
backover.c:237
#11 0x08090f2d in slap_response_play (op=0x8a84160, rs=0xb6f111c8) at
result.c:317
#12 0x080910cd in send_ldap_response (op=0x8a84160, rs=0xb6f111c8) at
result.c:391
#13 0x08091dd2 in slap_send_ldap_result (op=0x8a84160, rs=0xb6f111c8) at
result.c:638
#14 0x08103653 in bdb_modrdn (op=0x8a84160, rs=0xb6f111c8) at modrdn.c:784
#15 0x080f1c30 in overlay_op_walk (op=0x8a84160, rs=0xb6f111c8, which=op_modrdn,
oi=0x89fb040, on=0x0) at backover.c:507
#16 0x080f1de5 in over_op_func (op=0x8a84160, rs=0xb6f111c8, which=op_modrdn) at
backover.c:559
#17 0x080f1ecf in over_op_modrdn (op=0x8a84160, rs=0xb6f111c8) at
backover.c:599
#18 0x0809e220 in fe_op_modrdn (op=0x8a84160, rs=0xb6f111c8) at modrdn.c:318
#19 0x0809db83 in do_modrdn (op=0x8a84160, rs=0xb6f111c8) at modrdn.c:185
#20 0x0807ef0f in connection_operation (ctx=0xb6f112a4, arg_v=0x8a84160) at
connection.c:1129
#21 0x0807f3dc in connection_read_thread (ctx=0xb6f112a4, argv=0x10) at
connection.c:1257
#22 0x081e57a8 in ldap_int_thread_pool_wrapper (xpool=0x89bd968) at tpool.c:704
#23 0x00692371 in start_thread () from /lib/tls/libpthread.so.0
#24 0x00475ffe in clone () from /lib/tls/libc.so.6
(gdb) frame 4
#4  0x080bc142 in entry_schema_check (op=0xb6f10760, e=0x8a606dc, oldattrs=0x0,
manage=0, add_soc=1, text=0xb6f10738, 
    textbuf=0xb6f1040c "��@", textlen=256) at schema_check.c:87
87                      assert( a->a_vals[0].bv_val != NULL ); 
(gdb) p a
$1 = (Attribute *) 0xb6f78e34
(gdb) p a->a_vals
$2 = 0x8a93ef8
(gdb) p a->a_vals[0]
$3 = {bv_len = 0, bv_val = 0x0}

No solution comes to mind right now for the first problem; I'm investigating the
second to see where the NULL attr comes from.

p.