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

[hyc@symas.com]

ando@sys-net.it wrote:
> 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?
>   
Might want to try again with ElectricFence, or see if the other tools 
have an option to retain freed memory on a separate list (and delay it) 
before making it available for re-use.

-- 
  -- Howard Chu
  Chief Architect, Symas Corp.  http://www.symas.com
  Director, Highland Sun        http://highlandsun.com/hyc
  OpenLDAP Core Team            http://www.openldap.org/project/