Hi,
On Sun, 4 Jan 2015 20:16:58, Jakub Jelinek wrote:
>
> On Sun, Jan 04, 2015 at 11:07:31AM -0800, Mike Stump wrote:
>> On Jan 4, 2015, at 9:00 AM, Bernd Edlinger <bernd.edlin...@hotmail.de> wrote:
>>> It is due to a race condition in tsan itself, it cannot decide which access
>>> was the
>>> previous one and which was the second one, but our tsan tests are not meant
>>> as
>>> a functional test of the tsan runtime library, they are only meant to test
>>> the GCC
>>> instrumentation.
>>
>> Well, at least one test case that _is_ a functional test of the tsan runtime
>> library isn’t a bad idea.
There are of course numerous functional tests, but they are all in LLVM's tree
at /compiler-rt/trunk/test/tsan
>
> The GCC instrumentation can be tested just by scanning the *.optimized dumps
> or assembly. And perhaps the runtime test just be hidden by some special
> environment variable that the user acks he doesn't main spurious FAILs.
>
I never had suspected the sleep calls to play such an important role, If I did,
I would
have smuggled one in before checking in....
That's surely due to that there was no comment anywhere mentioning that race
condition. I wonder if there is a test for that in the LLVM tree? Probably
they
wouldn't consider that a BUG. I've looked deep in the implementation and I
saw, for every 8-byte word, there are 4 shadow words, each containing previous
accesses with call stack, and the __tsan_write8 functions just dont lock
a mutex because of performance reasons, if the application does not have
a race conditions tsan does not have a race either, if the application has a
race condition, there is a certain chance that both threads call __tsan_write8,
both look at the same shadow word, see nothing, and both write their
callstack in the same shadow cell. But tsan still gets at least 90% chance
to spot that. As a matter of fact, the tsan runtime is just _incredibly_ fast,
and catches errors, with a very high reliability. But it is racy by design.
Bernd.
> Jakub
