[Date Prev][Date Next]
Re: (ITS#3914) test030-relay frees already-freed memory
>>I think I've spotted the problem; the fix is in HEAD.
>Yes, the crash has moved again:-)
After applying your patch, I'm seeing something __really__ weird: now
valgrind yiells because memory is being freed twice; but slapd just
works fine, even with MALLOC_CHECK_=2. If I step in with gdb, I note
that performing the ldapcompare that's in test030 (with my latest
commit, rwm.c 1.62->1.63) the ava gets rewritten... in place! After
ber_dupbv()'ing the new value in the just free()'d
op->orc_ava->aa_value, the berval gets exactly the same memory it had
initially, but it's being malloc()'ed again by ber_dupbv(). I suspect
the fact that it gets __exactly__ the same memory tricks some memory
checkers like valgrind (and purify? I didn't check with it). Do you
still get the crash __without__ purify?
SysNet - via Dossi,8 27100 Pavia Tel: +390382573859 Fax: +390382476497