Julian Seward <jsew...@acm.org> writes: >> Is it possible for the DRD/Helgrind tools to detect this sort of >> double-write access behaviour? > > Both of them should be able to detect a write-vs-write race, if > that's what you mean.
But is that only if two threads race to write the same location at the same time? > >> Could I instrument QEMU so it marked the >> codegen buffer as one that should only grow upwards (modulo-patchable >> bits) so if anything re-wrote the buffer it could trigger an error? > > This is confusing. Both tools are able to detect races at a byte level > granularity. If you can show that QEMU doesn't race on individual writes > to its code buffer, isn't that good enough from a correctness > perspective? What I think has happened is: * thread a writes from code_buf_start a series of operations * thread b writes from code_buf_start over the top of thread a * thread b finalises the code buffer at code_buf_end<b> * thread a finalises the code buffer at code_buf_end<a> The result is a corrupted code buffer where one threads output has been stomped on by the other. I don't think they raced on the individual writes, just over wrote the previous work on the next schedule. > > J -- Alex Bennée ------------------------------------------------------------------------------ Is your legacy SCM system holding you back? Join Perforce May 7 to find out: • 3 signs your SCM is hindering your productivity • Requirements for releasing software faster • Expert tips and advice for migrating your SCM now http://p.sf.net/sfu/perforce _______________________________________________ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
