On Mon, Feb 7, 2011 at 2:05 PM, Konstantin Serebryany <
[email protected]> wrote:
>
> On Mon, Feb 7, 2011 at 2:59 PM, Bart Van Assche <[email protected]>wrote:
>
>> On Mon, Feb 7, 2011 at 9:28 AM, Konstantin Serebryany <
>> [email protected]> wrote:
>>
>>>
>>> On Sun, Feb 6, 2011 at 10:14 PM, Bart Van Assche <[email protected]>wrote:
>>>
>>>> On Sat, Feb 5, 2011 at 5:54 PM, Konstantin Serebryany <
>>>> [email protected]> wrote:
>>>>
>>>>>
>>>>> On Sat, Feb 5, 2011 at 7:36 PM, Bart Van Assche <[email protected]>wrote:
>>>>>
>>>>>> On Sat, Feb 5, 2011 at 2:22 PM, Konstantin Serebryany <
>>>>>> [email protected]> 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.
------------------------------------------------------------------------------
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/valgrind-users
