TSAN_NO_HISTORY misses races

[GoogleCodeExporter]

---------- Forwarded message ----------
From: Cedomir Segulja
Date: Mon, Sep 15, 2014 at 8:00 AM
Subject: DTSAN_NO_HISTORY bug?

Hi Dmitry,

I was playing around with the DTSAN_NO_HISTORY flag. As I understand
it purpose, when this flag is enabled, Tsan should still be able to
detect data races but it will not be able to point to the exact
location of the race. If this is correct, I think there is a bug. If
not, just ignore the rest of this email :)

Consider the following simple code:

T0 does: LOCK, UNLOCK, write to x
T1 then does: LOCK, UNLOCK, write to x

There is a race on x. Without DTSAN_NO_HISTORY, the first write to x
will increment T0's epoch, and the write by T1 will then find that
T0's entry in its threadClock (propagated from T0:UNLOCK to T1:LOCK)
is smaller than the epoch of x (updated on T0's write). Hence, the
HappensBefore in tsan_rtl.cc will return false, and the data race will
be reported.

With DTSAN_NO_HISTORY enabled, write to x will not increment T0's
epoch, and no data race will be reported.

I think this can be fixed by modifying MutexUnlock in
tsan_rtl_mutex.cc so that thread's epoch is incremented AFTER updating
lock's vector clock (this is how it is done in FastTrack).

There is a similar issue when forking threads: after a thread is
forked, the parent's epoch needs to be incremented. Otherwise, simple
code: T0: write to x, T1: write to x fails.

Please let me know what you think,
-- Cedomir

Original issue reported on code.google.com by dvyu...@google.com on 15 Sep 2014 at 9:05