On Fri, Feb 4, 2011 at 12:16 PM, Andrea Mazzoleni <amadva...@gmail.com> wrote:
>
> I likely found a problem in the DRD when using the --free-is-write
> option. The following test case reports an huge amount of errors that
> are not expected.
>
> Valgrind and helgrind report no error.
>
> The machine is a Ubuntu 10.4 x86 with valgrind 3.6.0 compiled from source.
>
> The program is compiled with: gcc -O1 -g -D_REENTRANT  multi.c -o
> multi -lpthread
>
> In a big application I have similar strange reports, even without
> using --free-is-write, so maybe --free-is-write is only a way to
> expose the bug.

The implementation of --free-is-write in DRD is based on the
assumption that all modifications of memory after a call to free() and
before a new malloc() call returns it again are errors. I'm afraid
this assumption is wrong (the memory allocator may touch such memory)
so I have removed the --free-is-write option again.

Regarding the behavior of DRD with --free-is-write=no: DRD in this
configuration is working reliably for many people since considerable
time. So the issues reported with this configuration are most likely
either application errors or false positives triggered by the
distro-specific libthread or libc implementation. One should keep in
mind that the data race detection algorithms in DRD and Helgrind are
different and hence that both tools may report different data races or
false positives.

Further feedback for the behavior of DRD with --free-is-write=no is welcome.

Bart.

------------------------------------------------------------------------------
The modern datacenter depends on network connectivity to access resources
and provide services. The best practices for maximizing a physical server's
connectivity to a physical network are well understood - see how these
rules translate into the virtual world? 
http://p.sf.net/sfu/oracle-sfdevnlfb
_______________________________________________
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Reply via email to