On Fri, Jan 16, 2015 at 8:42 PM, Bernd Edlinger
<bernd.edlin...@hotmail.de> wrote:
> Hi,
>
> On Fri, 16 Jan 2015 21:25:42, Dmitry Vyukov wrote:
>>
>> This is just a copy from llvm repo, right?
>> Looks good to me.
>>
>
> Thanks.
>
> Yes I found these test case in the llvm tree, and just adapted them
> to work in the gcc test suite.
>
> However, here is a small tweak in the positive test:
> That is we now use a tsan-invisible barrier_wait function
> instead of the not very reliable sleep(1).
>
> barrier_wait is bypassing the tsan interceptor, because
> it is accessed with dlsym (dlopen ("libpthread.so.0", RTLD_LAZY),
> "pthread_barrier_wait").+Kostya Hi Bernd, Yes, that email is marked in my inbox. Sorry for not answering earlier. I can't really make my mind on this. I would mildly prefer sleep's (if they work reliably!). Kostya, please chime in. This is equivalent to StealthNotification that we used in old data-race-test test suite: https://code.google.com/p/data-race-test/source/browse/trunk/unittest/test_utils.h#134 Kostya, you had experience with both approaches. What are you thoughts on this? StealthNotification definitely makes tests faster and more reliable. I can't really come up with any objective downsides. >> On Fri, Jan 16, 2015 at 10:17 AM, Bernd Edlinger >> <bernd.edlin...@hotmail.de> wrote: >>> Hi, >>> >>> >>> I think I should ping for this patch now: >>> https://gcc.gnu.org/ml/gcc-patches/2015-01/msg00599.html >>> >>> note that by mistake the change log referenced sanitizer.c instead of >>> sanitizer.def, consider that fixed on my local copy. >>> >>> >>> Thanks >>> Bernd. >>> >>> >>>> Date: Sun, 11 Jan 2015 14:15:54 +0100 >>>> >>>> Hi, >>>> >>>> >>>> >>>> On Sun, 4 Jan 2015 14:54:56, Bernd Edlinger wrote: >>>>> >>>>> Hi Jakub, >>>>> >>>>> >>>>> I think I have found a reasonable test case, see the attached patch file. >>>>> The use case is: a class that destroys an owned thread in the destructor. >>>>> The destructor sets the vptr again to thread::vptr but this should >>>>> _not_ trigger a diagnostic message, when the vptr does not really change. >>>>> >>>>> Jakub, this is another test case where the TREE_READONLY prevents >>>>> the tsan instrumentation. So I had first to install your patch: >>>>> >>>>> https://gcc.gnu.org/ml/gcc-patches/2014-12/msg01432.html >>>>> >>>>> ... to see the test case fail without my patch. >>>>> >>>> >>>> that has been installed in the meantime. >>>> >>>>> The patch installs cleanly on 4.9 and 4.8, however the 4.8 branch >>>>> has no tsan tests, so I would leave the test case away for 4.8. >>>>> >>>> >>>> I found, 4.8 does not have BT_FN_VOID_PTR_PTR, and no tsan tests >>>> at all, so it is probably not worth the effort. >>>> >>>>> Boot-strapped and regression-tested on x86_64-linux-gnu >>>>> OK for trunk and 4.9 + 4.8 branches? >>>>> >>>>> >>>>> Thanks >>>>> Bernd. >>>>> >>>>> >>>> >>>> I found some test cases in the clang tree, about the __tsan_vptr_update. >>>> So I thought I should use these instead of inventing new ones. >>>> >>>> Attached you'll find an updated patch with one positive and one negative >>>> test for vptr races. >>>> >>>> Tested with x86_64-linux-gnu. >>>> OK for trunk and 4.9 after a while? >>>> >>>> >>>> Thanks >>>> Bernd. >>>> >>> >
