TSan lies about access sizes

[GoogleCodeExporter]

TSan always reports min(previous, current) access size as the current access 
size. This can be very misleading.

Example:

#include <pthread.h>
#include <unistd.h>

volatile int x;

void *f(void* arg) {
  *((char*)&x) = 5;
}

void *g(void* arg) {
  usleep(1000000);
  x = 2;
}

int main(void) {
  pthread_t t[2];
  pthread_create(&t[0], NULL, f, 0);
  pthread_create(&t[1], NULL, g, 0);
  pthread_join(t[0], NULL);
  pthread_join(t[1], NULL);
  return 0;
}

TSan report:

==31694== WARNING: Possible data race during write of size 1 at 0x402090: {{{
==31694==    T2 (L{}):
==31694==     #0  g ./1
==31694==   Concurrent write(s) happened at (OR AFTER) these points:
==31694==    T1 (L{}):
==31694==     #0  f ./1
==31694==   Address 0x402090 is 0 bytes inside data symbol "x"
==31694==    Race verifier data: 0x40069C,0x400674
==31694== }}}

Original issue reported on code.google.com by euge...@google.com on 30 Aug 2011 at 9:13

[GoogleCodeExporter]

I am not sure if this can be fixed with zero performance penalty

Original comment by kcc@chromium.org on 30 Aug 2011 at 3:23

[GoogleCodeExporter]

Moreover, I suspect that it messes up the address as well.

Original comment by dvyu...@google.com on 30 Aug 2011 at 3:43

[GoogleCodeExporter]

> I am not sure if this can be fixed with zero performance penalty
Can we store the actual address/size in some buffer and use it only when 
reporting?

Original comment by timurrrr on 30 Aug 2011 at 3:50

[GoogleCodeExporter]

> I am not sure if this can be fixed with zero performance penalty

Sounds like a challenge... are you ready to set a bounty for that? :)

Original comment by dvyu...@google.com on 30 Aug 2011 at 3:56