> I would be interested to know if that is useful. It works and it is certainly useful!
Few more questions: - as I see, the interceptors for pthread spin locks are not implemented yet. Is that a principal limitation or just a matter of time? - If a spin lock/unlock routines are inlined by the compiler there is no way for valgrind to intercept them, right? Need to force the compiler not to inline them... - How to show file names with full path in thrcheck's output? Thanks! --kcc On Nov 8, 2007 3:54 PM, Julian Seward <[EMAIL PROTECTED]> wrote: > > > I assume that valgrind can not track history of accesses to all memory > > addresses with corresponding stacks. Too expensive. > > True. > > > May be it can keep such history for those addresses where a race has been > > detected? > > That could be possible at reasonable cost. > > > But it will not help if the memory was accessed only once in the first > > thread. > > True. Oh well. > > > 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 > > You can sort-of do this already. Rerun with --trace-addr=0x5C52028 > and --trace-level=1. This will give you a 1-line summary for each > access to 0x5C52028. At --trace-level=2 you get a complete stack > trace. > > I would be interested to know if that is useful. > > J > ------------------------------------------------------------------------- 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
