| Issue |
134344
|
| Summary |
[TSAN] Threadsanitizer false negative
|
| Labels |
false-negative
|
| Assignees |
|
| Reporter |
jaidevshastri
|
Hi,
TSAN reports no race when enabled with `-fsanitize=thread` on the test program below. This behavior has been observed with precompiled llvm+clang binaries (v16) and compiled llvm project binaries (v16.0.6).
```
#include <stdio.h>
#include <pthread.h>
pthread_mutex_t l;
int x = 1;
void* writer1(void* _) {
pthread_mutex_lock(&l);
x = 0; //Wx1
pthread_mutex_unlock(&l);
return NULL;
}
void* writer2(void* _) {
pthread_mutex_lock(&l);
pthread_mutex_unlock(&l);
x = 1; //Wx2
return NULL;
}
int main() {
pthread_t thr[2];
pthread_mutex_init(&l, NULL);
pthread_create(&thr[0], NULL, writer1, NULL);
pthread_create(&thr[1], NULL, writer2, NULL);
pthread_join(thr[0], NULL);
pthread_join(thr[1], NULL);
pthread_mutex_destroy(&l);
return 0;
}
```
When writer1 acquires the lock `l` before writer2, the epoch information seems to be transferred such that the happens-before (HB) analysis on the shared memory `x` returns true: Wx1 HB Wx2. TSAN thus fails to assert the race between Wx1 and Wx2.
When writer2 acquires the lock `l` before writer1, the happens-before analysis correctly asserts the lack of ordering between Wx1 and Wx2, thereby reporting race.
Could the above behavior be clarified? Specifically, I would like to know if this is a limitation of pure HB analysis or a limitation/bug of TSAN.
I am also attaching my understanding of the two scheduling sequences for the test program and the vector clock information for reference.
[Tsan-norace-seq.pdf](https://github.com/user-attachments/files/19598094/Tsan-norace-seq.pdf)
[Tsan-race-sequence.pdf](https://github.com/user-attachments/files/19598095/Tsan-race-sequence.pdf)
Any information on this issue would be much appreciated.
Thanks!
Jaidev
![]()
_______________________________________________
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
