[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: (ITS#3914) test030-relay frees already-freed memory

h.b.furuseth@usit.uio.no wrote:

>>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