Dear valgrind developers,
I have a question regarding thrcheck.
If thrcheck detects a race it prints something like this:
==30205== Possible data race during write of size 4 at 0x5C52028
==30205== at 0x80484D7: main (heap_race.c:18)
==30205== Old state: owned exclusively by thread #2
==30205== New state: shared-modified by threads #1, #2
==30205== Reason: this thread, #1, holds no locks at all
So, the debug info gives us the line of code where the *second* access to
this memory has happened.
But it does not give any information about the *first* access.
Of course, in a simple program the first access could be found by just
looking at the code.
If the accessed memory is global/static variable, we can run the program
under gdb with watchpoint.
However, if the memory in question is dynamically allocated and buried deep
inside some structures, we are in trouble.
Do you have any suggestion how to find the first access in a general case?
I assume that valgrind can not track history of accesses to all memory
addresses with corresponding stacks. Too expensive.
May be it can keep such history for those addresses where a race has been
detected?
But it will not help if the memory was accessed only once in the first
thread.
Another way is to run valgrind twice -- the first run will act as usual and
the second run will take the report of the first one and treat addresses in
the report specially. Though, of course, running valgrind twice is not fun.
What I would like to see is:
==30205== Possible data race during write of size 4 at 0x5C52028
==30205== at 0x80484D7: main (heap_race.c:18)
==30205== Old state: owned exclusively by thread #2
==30205== New state: shared-modified by threads #1, #2
==30205== Reason: this thread, #1, holds no locks at all
*==30205== One of the previous accesses to 0x5C52028 in thread #2 was
==30205== at 0x1234567: somewhere (somewhere.c:123)
==30205== by 0x80484D7: main (heap_race.c:18)
*
Actually, these two approaches are complimentary.
Ideas? Suggestions?
Thanks,
--kcc
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Valgrind-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/valgrind-developers
