| Summary: | __sync_fetch_and_add reported as read instead of as write | ||
|---|---|---|---|
| Product: | [Developer tools] valgrind | Reporter: | mephi42 |
| Component: | memcheck | Assignee: | Julian Seward <jseward> |
| Status: | RESOLVED INTENTIONAL | ||
| Severity: | normal | ||
| Priority: | NOR | ||
| Version First Reported In: | 3.12.0 | ||
| Target Milestone: | --- | ||
| Platform: | Other | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed/Implemented In: | ||
| Sentry Crash Report: | |||
You're right. However, how this works is associated with how VEX's CAS primitive is implemented, and fixing it would be quite some work. So I think this is unlikely to get fixed. |
For the following test program: #include <stdlib.h> int main() { int *p = malloc(4); if (!p) { return 1; } *p = 0; free(p); __sync_fetch_and_add(p, -1); } valgrind reports the following: ==81== Invalid read of size 4 ==81== at 0x4005BE: main (test.c:7) ==81== Address 0x51f8040 is 0 bytes inside a block of size 4 free'd ==81== at 0x4C2BCDD: free (vg_replace_malloc.c:530) ==81== by 0x4005B9: main (test.c:6) ==81== Block was alloc'd at ==81== at 0x4C2ABE3: malloc (vg_replace_malloc.c:299) ==81== by 0x400591: main (test.c:3) I believe this problem should be reported as an invalid write or an invalid read followed by an invalid write, but not simply as an invalid read.