|
From: Andrea M. <ama...@gm...> - 2011-02-04 11:17:00
|
Hi,
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.
Here the C program:
#include <pthread.h>
#include <unistd.h>
#include <stdlib.h>
#include <stdio.h>
#include <pthread.h>
#include <string.h>
static pthread_mutex_t thread_mutex = PTHREAD_MUTEX_INITIALIZER;
unsigned term_count;
#define SIZE 22816
#define N 10
#define M 1000
void* thread_func(void* arg)
{
unsigned i;
for(i=0;i<M;++i) {
void* ptr;
printf("a");
ptr = malloc(SIZE);
printf("s");
memset(ptr, 0, SIZE);
printf("f");
free(ptr);
}
pthread_mutex_lock(&thread_mutex);
++term_count;
pthread_mutex_unlock(&thread_mutex);
pthread_exit(NULL);
return 0;
}
int main(int argc, char **argv)
{
pthread_t thread;
int i;
for (i=0;i<N; i++ ) {
if (pthread_create(&thread, 0, thread_func, 0) != 0) {
abort();
}
}
while (1) {
unsigned curr_term;
pthread_mutex_lock(&thread_mutex);
curr_term = term_count;
pthread_mutex_unlock(&thread_mutex);
if (curr_term == N)
break;
sleep(1);
}
return 0;
}
Here the DRD report:
==391== drd, a thread error detector
==391== Copyright (C) 2006-2010, and GNU GPL'd, by Bart Van Assche.
==391== Using Valgrind-3.6.0 and LibVEX; rerun with -h for copyright info
==391== Command: ./multi
==391==
--391-- Valgrind options:
--391-- --tool=drd
--391-- --free-is-write=yes
--391-- -v
--391-- Contents of /proc/version:
--391-- Linux version 2.6.32-27-generic (buildd@roseapple) (gcc
version 4.4.3 (Ubuntu 4.4.3-4ubuntu5) ) #49-Ubuntu SMP Wed Dec 1
23:52:12 UTC 2010
--391-- Arch and hwcaps: X86, x86-sse1-sse2
--391-- Page sizes: currently 4096, max supported 4096
--391-- Valgrind library directory: /usr/local/lib/valgrind
--391-- Reading syms from /lib/ld-2.11.1.so (0x4000000)
--391-- Considering /lib/ld-2.11.1.so ..
--391-- .. CRC mismatch (computed d005eb74 wanted 53dc8daf)
--391-- Considering /usr/lib/debug/lib/ld-2.11.1.so ..
--391-- .. CRC is valid
--391-- Reading syms from
/home/am/Desktop/drm/api/debugnix/test_drd/multi (0x8048000)
--391-- Reading syms from /usr/local/lib/valgrind/drd-x86-linux (0x38000000)
--391-- object doesn't have a dynamic symbol table
--391-- Reading suppressions file: /usr/local/lib/valgrind/default.supp
--391-- Reading syms from
/usr/local/lib/valgrind/vgpreload_core-x86-linux.so (0x401f000)
--391-- Reading syms from
/usr/local/lib/valgrind/vgpreload_drd-x86-linux.so (0x4022000)
--391-- REDIR: 0x4016290 (strlen) redirected to 0x402ff60 (strlen)
--391-- Reading syms from /lib/tls/i686/cmov/libpthread-2.11.1.so (0x4050000)
--391-- Considering /lib/tls/i686/cmov/libpthread-2.11.1.so ..
--391-- .. CRC mismatch (computed 38da17dd wanted d3835c81)
--391-- Considering /usr/lib/debug/lib/tls/i686/cmov/libpthread-2.11.1.so ..
--391-- .. CRC is valid
--391-- Reading syms from /lib/tls/i686/cmov/libc-2.11.1.so (0x406a000)
--391-- Considering /lib/tls/i686/cmov/libc-2.11.1.so ..
--391-- .. CRC mismatch (computed da84aea3 wanted 8ac7aa97)
--391-- Considering /usr/lib/debug/lib/tls/i686/cmov/libc-2.11.1.so ..
--391-- .. CRC is valid
--391-- REDIR: 0x4055d70 (pthread_create@@GLIBC_2.1) redirected to
0x402d5a0 (pthread_create@*)
--391-- REDIR: 0x40d9660 (calloc) redirected to 0x402610f (calloc)
--391-- REDIR: 0x40d9f40 (malloc) redirected to 0x4026e2b (malloc)
--391-- REDIR: 0x40d9e60 (free) redirected to 0x4026a45 (free)
--391-- REDIR: 0x4057f10 (pthread_mutex_lock) redirected to 0x402e0b0
(pthread_mutex_lock)
--391-- REDIR: 0x4059400 (pthread_mutex_unlock) redirected to
0x402eb60 (pthread_mutex_unlock)
--391-- Reading syms from /lib/libgcc_s.so.1 (0x47e3000)
--391-- Considering /lib/libgcc_s.so.1 ..
--391-- .. CRC mismatch (computed 75b2cc22 wanted fffc9534)
--391-- object doesn't have a symbol table
--391-- REDIR: 0x40dd730 (strlen) redirected to 0x401f44c (_vgnU_ifunc_wrapper)
--391-- REDIR: 0x40dd770 (__strlen_sse2) redirected to 0x402ff40 (strlen)
--391-- REDIR: 0x405b3a0 (pthread_once) redirected to 0x4027f70 (pthread_once)
==391== Thread 3:
==391== Conflicting store by thread 3 at 0x043c6550 size 22816
==391== at 0x4026ACA: free (vg_replace_malloc.c:366)
==391== by 0x804878A: thread_func (multi.c:33)
==391== by 0x402DAAB: vgDrd_thread_wrapper (drd_pthread_intercepts.c:281)
==391== by 0x405596D: start_thread (pthread_create.c:300)
==391== by 0x4137A4D: clone (clone.S:130)
==391== Allocation context: unknown.
==391== Other segment start (thread 2)
==391== (thread finished, call stack no longer available)
==391== Other segment end (thread 2)
==391== (thread finished, call stack no longer available)
==391==
==391==
==391== ERROR SUMMARY: 8000 errors from 1 contexts (suppressed:
12190873 from 195)
==391==
==391== 8000 errors in context 1 of 1:
==391== Conflicting store by thread 3 at 0x043c6550 size 22816
==391== at 0x4026ACA: free (vg_replace_malloc.c:366)
==391== by 0x804878A: thread_func (multi.c:33)
==391== by 0x402DAAB: vgDrd_thread_wrapper (drd_pthread_intercepts.c:281)
==391== by 0x405596D: start_thread (pthread_create.c:300)
==391== by 0x4137A4D: clone (clone.S:130)
==391== Address 0x43c6550 is at offset 0 from 0x43c6550. Allocation context:
==391== at 0x40261EF: calloc (vg_replace_malloc.c:467)
==391== by 0x4010CDB: _dl_allocate_tls (dl-tls.c:300)
==391== by 0x40562E2: pthread_create@@GLIBC_2.1 (allocatestack.c:561)
==391== by 0x402D6D4: pthread_create@* (drd_pthread_intercepts.c:416)
==391== by 0x80486C3: main (multi.c:51)
==391== Other segment start (thread 1)
==391== (thread finished, call stack no longer available)
==391== Other segment end (thread 1)
==391== (thread finished, call stack no longer available)
==391== Other segment start (thread 1)
==391== (thread finished, call stack no longer available)
==391== Other segment end (thread 1)
==391== (thread finished, call stack no longer available)
==391== Other segment start (thread 1)
==391== (thread finished, call stack no longer available)
==391== Other segment end (thread 1)
==391== (thread finished, call stack no longer available)
==391== Other segment start (thread 1)
==391== (thread finished, call stack no longer available)
==391== Other segment end (thread 1)
==391== (thread finished, call stack no longer available)
==391== Other segment start (thread 1)
==391== (thread finished, call stack no longer available)
==391== Other segment end (thread 1)
==391== (thread finished, call stack no longer available)
==391== Other segment start (thread 2)
==391== (thread finished, call stack no longer available)
==391== Other segment end (thread 2)
==391== (thread finished, call stack no longer available)
==391== Other segment start (thread 4)
==391== (thread finished, call stack no longer available)
==391== Other segment end (thread 4)
==391== (thread finished, call stack no longer available)
==391== Other segment start (thread 5)
==391== (thread finished, call stack no longer available)
==391== Other segment end (thread 5)
==391== (thread finished, call stack no longer available)
==391== Other segment start (thread 6)
==391== (thread finished, call stack no longer available)
==391== Other segment end (thread 6)
==391== (thread finished, call stack no longer available)
==391== Other segment start (thread 7)
==391== (thread finished, call stack no longer available)
==391== Other segment end (thread 7)
==391== (thread finished, call stack no longer available)
==391== Other segment start (thread 8)
==391== (thread finished, call stack no longer available)
==391== Other segment end (thread 8)
==391== (thread finished, call stack no longer available)
==391== Other segment start (thread 9)
==391== (thread finished, call stack no longer available)
==391== Other segment end (thread 9)
==391== (thread finished, call stack no longer available)
==391==
--391--
--391-- used_suppression: 66 drd-ld
--391-- used_suppression: 12190789 drd-libc-stdio
--391-- used_suppression: 18 drd-libpthread-_Unwind_ForcedUnwind
==391==
==391== ERROR SUMMARY: 8000 errors from 1 contexts (suppressed:
12190873 from 195)
Ciao,
Andrea
|
|
From: Bart V. A. <bva...@ac...> - 2011-02-04 19:16:35
|
On Fri, Feb 4, 2011 at 12:16 PM, Andrea Mazzoleni <ama...@gm...> 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. |
|
From: Konstantin S. <kon...@gm...> - 2011-02-05 13:22:53
|
FYI ThreadSanitizer will not report anything on this test, even with --free-is-write (which is on by default) because this tool assumes the malloc implementation to be correct and ignores every access inside malloc and friends. I haven't seen any false positives due to --free-is-write (in ThreadSanitizer) over last ~6 months, but we found tons of real races with this flag. Just a fresh example: http://code.google.com/p/chromium/issues/detail?id=72042 --kcc On Fri, Feb 4, 2011 at 10:16 PM, Bart Van Assche <bva...@ac...> wrote: > On Fri, Feb 4, 2011 at 12:16 PM, Andrea Mazzoleni <ama...@gm...> > 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 > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users > > > |
|
From: Bart V. A. <bva...@ac...> - 2011-02-05 16:36:39
|
On Sat, Feb 5, 2011 at 2:22 PM, Konstantin Serebryany < kon...@gm...> wrote: > FYI > ThreadSanitizer will not report anything on this test, even with > --free-is-write (which is on by default) because this tool assumes the > malloc implementation to be correct and ignores every access inside malloc > and friends. > I haven't seen any false positives due to --free-is-write (in > ThreadSanitizer) over last ~6 months, but we found tons of real races with > this flag. Just a fresh example: > http://code.google.com/p/chromium/issues/detail?id=72042 > Hello Konstantin, Has that --free-is-write feature already been tested in combination with custom memory allocators ? Bart. |
|
From: Konstantin S. <kon...@gm...> - 2011-02-05 16:55:23
|
On Sat, Feb 5, 2011 at 7:36 PM, Bart Van Assche <bva...@ac...> wrote: > On Sat, Feb 5, 2011 at 2:22 PM, Konstantin Serebryany < > kon...@gm...> wrote: > >> FYI >> ThreadSanitizer will not report anything on this test, even with >> --free-is-write (which is on by default) because this tool assumes the >> malloc implementation to be correct and ignores every access inside malloc >> and friends. >> I haven't seen any false positives due to --free-is-write (in >> ThreadSanitizer) over last ~6 months, but we found tons of real races with >> this flag. Just a fresh example: >> http://code.google.com/p/chromium/issues/detail?id=72042 >> > > Hello Konstantin, > > Has that --free-is-write feature already been tested in combination with > custom memory allocators ? > What kind of custom memory allocators? We regularly run it with programs linked against tcmalloc. --kcc > Bart. > |
|
From: Bart V. A. <bva...@ac...> - 2011-02-06 19:15:09
|
On Sat, Feb 5, 2011 at 5:54 PM, Konstantin Serebryany < kon...@gm...> wrote: > > On Sat, Feb 5, 2011 at 7:36 PM, Bart Van Assche <bva...@ac...>wrote: > >> On Sat, Feb 5, 2011 at 2:22 PM, Konstantin Serebryany < >> kon...@gm...> wrote: >> >>> FYI >>> ThreadSanitizer will not report anything on this test, even with >>> --free-is-write (which is on by default) because this tool assumes the >>> malloc implementation to be correct and ignores every access inside malloc >>> and friends. >>> I haven't seen any false positives due to --free-is-write (in >>> ThreadSanitizer) over last ~6 months, but we found tons of real races with >>> this flag. Just a fresh example: >>> http://code.google.com/p/chromium/issues/detail?id=72042 >>> >> >> Hello Konstantin, >> >> Has that --free-is-write feature already been tested in combination with >> custom memory allocators ? >> > What kind of custom memory allocators? > We regularly run it with programs linked against tcmalloc. > Hello Konstantin, With "custom memory allocators" I was referring to those using the VG_USERREQ__MALLOCLIKE_BLOCK and VG_USERREQ__FREELIKE_BLOCK client requests and not to those that replace malloc() like e.g. tcmalloc. Bart. |
|
From: Konstantin S. <kon...@gm...> - 2011-02-07 08:32:29
|
On Sun, Feb 6, 2011 at 10:14 PM, Bart Van Assche <bva...@ac...> wrote: > On Sat, Feb 5, 2011 at 5:54 PM, Konstantin Serebryany < > kon...@gm...> wrote: > >> >> On Sat, Feb 5, 2011 at 7:36 PM, Bart Van Assche <bva...@ac...>wrote: >> >>> On Sat, Feb 5, 2011 at 2:22 PM, Konstantin Serebryany < >>> kon...@gm...> wrote: >>> >>>> FYI >>>> ThreadSanitizer will not report anything on this test, even with >>>> --free-is-write (which is on by default) because this tool assumes the >>>> malloc implementation to be correct and ignores every access inside malloc >>>> and friends. >>>> I haven't seen any false positives due to --free-is-write (in >>>> ThreadSanitizer) over last ~6 months, but we found tons of real races with >>>> this flag. Just a fresh example: >>>> http://code.google.com/p/chromium/issues/detail?id=72042 >>>> >>> >>> Hello Konstantin, >>> >>> Has that --free-is-write feature already been tested in combination with >>> custom memory allocators ? >>> >> What kind of custom memory allocators? >> We regularly run it with programs linked against tcmalloc. >> > > Hello Konstantin, > > With "custom memory allocators" I was referring to those using the > VG_USERREQ__MALLOCLIKE_BLOCK and VG_USERREQ__FREELIKE_BLOCK client requests > and not to those that replace malloc() like e.g. tcmalloc. > ThreadSanitizer does not support VG_USERREQ__FREELIKE_BLOCK -- never found a use for it yet. However if a program uses a lot of custom free lists it could be useful (and it will be trivial to implement). --kcc > Bart. > > > |
|
From: Bart V. A. <bva...@ac...> - 2011-02-07 12:00:02
|
On Mon, Feb 7, 2011 at 9:28 AM, Konstantin Serebryany < kon...@gm...> wrote: > > On Sun, Feb 6, 2011 at 10:14 PM, Bart Van Assche <bva...@ac...>wrote: > >> On Sat, Feb 5, 2011 at 5:54 PM, Konstantin Serebryany < >> kon...@gm...> wrote: >> >>> >>> On Sat, Feb 5, 2011 at 7:36 PM, Bart Van Assche <bva...@ac...>wrote: >>> >>>> On Sat, Feb 5, 2011 at 2:22 PM, Konstantin Serebryany < >>>> kon...@gm...> wrote: >>>> >>>>> FYI >>>>> ThreadSanitizer will not report anything on this test, even with >>>>> --free-is-write (which is on by default) because this tool assumes the >>>>> malloc implementation to be correct and ignores every access inside malloc >>>>> and friends. >>>>> I haven't seen any false positives due to --free-is-write (in >>>>> ThreadSanitizer) over last ~6 months, but we found tons of real races with >>>>> this flag. Just a fresh example: >>>>> http://code.google.com/p/chromium/issues/detail?id=72042 >>>>> >>>> >>>> Hello Konstantin, >>>> >>>> Has that --free-is-write feature already been tested in combination with >>>> custom memory allocators ? >>>> >>> What kind of custom memory allocators? >>> We regularly run it with programs linked against tcmalloc. >>> >> >> Hello Konstantin, >> >> With "custom memory allocators" I was referring to those using the >> VG_USERREQ__MALLOCLIKE_BLOCK and VG_USERREQ__FREELIKE_BLOCK client requests >> and not to those that replace malloc() like e.g. tcmalloc. >> > > ThreadSanitizer does not support VG_USERREQ__FREELIKE_BLOCK -- never found > a use for it yet. > However if a program uses a lot of custom free lists it could be useful > (and it will be trivial to implement). > Hello Konstantin, Sure, I don't doubt that implementing support for VG_USERREQ__FREELIKE_BLOCK in TS would be trivial to implement. What might be hard to implement regarding --free-is-write is to ignore the memory accesses inside the custom allocator. This is because such a custom allocator issues VG_USERREQ__MALLOCLIKE_BLOCK after it has finished updating its internal data structures and because the tool is not informed when the custom memory allocator in the client starts updating its internal data structures. Bart. |
|
From: Konstantin S. <kon...@gm...> - 2011-02-07 13:05:46
|
On Mon, Feb 7, 2011 at 2:59 PM, Bart Van Assche <bva...@ac...> wrote: > On Mon, Feb 7, 2011 at 9:28 AM, Konstantin Serebryany < > kon...@gm...> wrote: > >> >> On Sun, Feb 6, 2011 at 10:14 PM, Bart Van Assche <bva...@ac...>wrote: >> >>> On Sat, Feb 5, 2011 at 5:54 PM, Konstantin Serebryany < >>> kon...@gm...> wrote: >>> >>>> >>>> On Sat, Feb 5, 2011 at 7:36 PM, Bart Van Assche <bva...@ac...>wrote: >>>> >>>>> On Sat, Feb 5, 2011 at 2:22 PM, Konstantin Serebryany < >>>>> kon...@gm...> wrote: >>>>> >>>>>> FYI >>>>>> ThreadSanitizer will not report anything on this test, even with >>>>>> --free-is-write (which is on by default) because this tool assumes the >>>>>> malloc implementation to be correct and ignores every access inside malloc >>>>>> and friends. >>>>>> I haven't seen any false positives due to --free-is-write (in >>>>>> ThreadSanitizer) over last ~6 months, but we found tons of real races with >>>>>> this flag. Just a fresh example: >>>>>> http://code.google.com/p/chromium/issues/detail?id=72042 >>>>>> >>>>> >>>>> Hello Konstantin, >>>>> >>>>> Has that --free-is-write feature already been tested in combination >>>>> with custom memory allocators ? >>>>> >>>> What kind of custom memory allocators? >>>> We regularly run it with programs linked against tcmalloc. >>>> >>> >>> Hello Konstantin, >>> >>> With "custom memory allocators" I was referring to those using the >>> VG_USERREQ__MALLOCLIKE_BLOCK and VG_USERREQ__FREELIKE_BLOCK client requests >>> and not to those that replace malloc() like e.g. tcmalloc. >>> >> >> ThreadSanitizer does not support VG_USERREQ__FREELIKE_BLOCK -- never >> found a use for it yet. >> However if a program uses a lot of custom free lists it could be useful >> (and it will be trivial to implement). >> > > Hello Konstantin, > > Sure, I don't doubt that implementing support for > VG_USERREQ__FREELIKE_BLOCK in TS would be trivial to implement. What might > be hard to implement regarding --free-is-write is to ignore the memory > accesses inside the custom allocator. Why? Just use ANNOTATE_IGNORE_READS_AND_WRITES_BEGIN/END This will of course hide races if the custom allocator itself is buggy. --kcc > This is because such a custom allocator issues VG_USERREQ__MALLOCLIKE_BLOCK > after it has finished updating its internal data structures and because the > tool is not informed when the custom memory allocator in the client starts > updating its internal data structures. > > Bart. > |
|
From: Bart V. A. <bva...@ac...> - 2011-02-07 17:37:21
|
On Mon, Feb 7, 2011 at 2:05 PM, Konstantin Serebryany < kon...@gm...> wrote: > > On Mon, Feb 7, 2011 at 2:59 PM, Bart Van Assche <bva...@ac...>wrote: > >> On Mon, Feb 7, 2011 at 9:28 AM, Konstantin Serebryany < >> kon...@gm...> wrote: >> >>> >>> On Sun, Feb 6, 2011 at 10:14 PM, Bart Van Assche <bva...@ac...>wrote: >>> >>>> On Sat, Feb 5, 2011 at 5:54 PM, Konstantin Serebryany < >>>> kon...@gm...> wrote: >>>> >>>>> >>>>> On Sat, Feb 5, 2011 at 7:36 PM, Bart Van Assche <bva...@ac...>wrote: >>>>> >>>>>> On Sat, Feb 5, 2011 at 2:22 PM, Konstantin Serebryany < >>>>>> kon...@gm...> wrote: >>>>>> >>>>>>> FYI >>>>>>> ThreadSanitizer will not report anything on this test, even with >>>>>>> --free-is-write (which is on by default) because this tool assumes the >>>>>>> malloc implementation to be correct and ignores every access inside malloc >>>>>>> and friends. >>>>>>> I haven't seen any false positives due to --free-is-write (in >>>>>>> ThreadSanitizer) over last ~6 months, but we found tons of real races with >>>>>>> this flag. Just a fresh example: >>>>>>> http://code.google.com/p/chromium/issues/detail?id=72042 >>>>>>> >>>>>> >>>>>> Hello Konstantin, >>>>>> >>>>>> Has that --free-is-write feature already been tested in combination >>>>>> with custom memory allocators ? >>>>>> >>>>> What kind of custom memory allocators? >>>>> We regularly run it with programs linked against tcmalloc. >>>>> >>>> >>>> Hello Konstantin, >>>> >>>> With "custom memory allocators" I was referring to those using the >>>> VG_USERREQ__MALLOCLIKE_BLOCK and VG_USERREQ__FREELIKE_BLOCK client requests >>>> and not to those that replace malloc() like e.g. tcmalloc. >>>> >>> >>> ThreadSanitizer does not support VG_USERREQ__FREELIKE_BLOCK -- never >>> found a use for it yet. >>> However if a program uses a lot of custom free lists it could be useful >>> (and it will be trivial to implement). >>> >> >> Hello Konstantin, >> >> Sure, I don't doubt that implementing support for >> VG_USERREQ__FREELIKE_BLOCK in TS would be trivial to implement. What might >> be hard to implement regarding --free-is-write is to ignore the memory >> accesses inside the custom allocator. > > > Why? Just use ANNOTATE_IGNORE_READS_AND_WRITES_BEGIN/END > This will of course hide races if the custom allocator itself is buggy. > > --kcc > > >> This is because such a custom allocator issues >> VG_USERREQ__MALLOCLIKE_BLOCK after it has finished updating its internal >> data structures and because the tool is not informed when the custom memory >> allocator in the client starts updating its internal data structures. >> > Hi Konstantin, As anyone can see in <valgrind/valgrind.h> there is currently no requirement on custom allocators to invoke ANNOTATE_IGNORE_READS_AND_WRITES_BEGIN/END. Thanks for confirming that it is not possible to implement --free-is-write correctly without changing the client-tool interface in a backwards-incompatible way. Bart. |
|
From: Konstantin S. <kon...@gm...> - 2011-02-07 18:29:31
|
> > As anyone can see in <valgrind/valgrind.h> there is currently no > requirement on custom allocators to invoke > ANNOTATE_IGNORE_READS_AND_WRITES_BEGIN/END. Thanks for confirming that it is > not possible to implement --free-is-write correctly without changing the > client-tool interface in a backwards-incompatible way. > You are welcome! :) --kcc |
|
From: Bart V. A. <bva...@ac...> - 2011-03-12 14:29:22
|
On Fri, Feb 4, 2011 at 12:16 PM, Andrea Mazzoleni <ama...@gm...> 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. > [ ... ] Sorry that it took so long, but I think I have found and fixed the problem that was present in the previous implementation of the --free-is-write option in DRD. The new implementation is present on the trunk in r11636. Please have a look at the documented limitations in the updated manual too. Bart. |