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.
>
> 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
