[Date Prev][Date Next]
Re: (ITS#3914) test030-relay frees already-freed memory
> email@example.com 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/