Summary: | False Positive Warning on std::atomic_bool | ||
---|---|---|---|
Product: | [Developer tools] valgrind | Reporter: | Дилян Палаузов <dilyan.palauzov> |
Component: | helgrind | Assignee: | Julian Seward <jseward> |
Status: | CONFIRMED --- | ||
Severity: | normal | CC: | faure, jhasse, pjfloyd |
Priority: | NOR | ||
Version: | 3.9.0 | ||
Target Milestone: | --- | ||
Platform: | Compiled Sources | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: |
Description
Дилян Палаузов
2013-11-20 21:04:46 UTC
Another example in pure C. According the documentation of libc,, the type sig_atomic_t is defined as "Reading and writing this data type is guaranteed to happen in a single instruction, so there's no way for a handler to run “in the middle” of an access. " (http://www.gnu.org/software/libc/manual/html_node/Atomic-Types.html) I understand this in a way, that reading and writing on sig_atomic_t is guaranteed to be atomic and causes no data races.. Running this program #include <pthread.h> #include <signal.h> sig_atomic_t a = 3; void* run() { a = 4; return NULL; } int main() { pthread_t p; pthread_create (&p, NULL, run, NULL); a = 5; pthread_join (p, NULL); return 0; } with the mentioned compilers (gcc -O0 -g -o test test.c -lpthread) , produces the warning ---Thread-Announcement------------------------------------------ Thread #1 is the program's root thread ---Thread-Announcement------------------------------------------ Thread #2 was created at 0x513C5DE: clone (in /lib64/libc-2.17.so) by 0x4E3CFC4: do_clone.constprop.4 (in /lib64/libpthread-2.17.so) by 0x4E3E438: pthread_create@@GLIBC_2.2.5 (in /lib64/libpthread-2.17.so) by 0x4C2F588: pthread_create_WRK (in /usr/lib64/valgrind/vgpreload_helgrind-amd64-linux.so) by 0x4006A3: main (test.c:13) ---------------------------------------------------------------- Possible data race during write of size 4 at 0x600B08 by thread #1 Locks held: none at 0x4006A4: main (test.c:14) This conflicts with a previous write of size 4 by thread #2 Locks held: none at 0x400670: run (test.c:7) by 0x4C2F72D: mythread_wrapper (in /usr/lib64/valgrind/vgpreload_helgrind-amd64-linux.so) by 0x4E3DDDE: start_thread (in /lib64/libpthread-2.17.so) However there is no data race at all, as reading or writing to sig_action_t variables is atomic. Thus the expected output of helgrind is no data races et al. I can confirm this behavior, seems like the suppression files must be extended to ignore anything happening within std::atomic* ? At least on x86, yes, there suppression files are the only solution since the CPU takes care of cache synchronization so non-atomic read/writes lead to the same assembly as atomic read/writes. On other architectures like ARM we probably don't want such suppressions to be enabled. |