|
From: Bart V. A. <bar...@gm...> - 2006-08-15 08:15:36
|
On 8/15/06, Nicholas Nethercote <nj...@cs...> wrote: > > On Mon, 14 Aug 2006, Bart Van Assche wrote: > > > A proof-of-concept version of drd is available at the following > location: > > The code itself looks pretty good, judging from a quick look-over. Please note that the valgrind patch I made available breaks a feature of Valgrind (see also drd/TODO.txt): currently Valgrind handles clone() calls originating from outside pthread_create() correctly. With my patch such clone() calls cause a memory leak (the associated thread remains in Vg_Empty state and never reaches Vg_Zombie). This can be solved easily however. > This version is not yet ready for a release -- e.g. it does not yet > support > > floating-point instructions, and uses more memory than acceptable for > some > > test cases. But it works well enough to demonstrate the DIOTA data race > > detection algorithm. And for the cases I tested, it works consistenly > and > > reliably. > > Good. How much memory does it use? Does it still have one shadow word > per > memory word like Helgrind? Two bits per accessed byte per segment (an access is either a read or a write). A new segment is created upon most pthread_...() calls. > ==5637== Detected data races. Context: > > [...] > > ==5637== Actual data races: > > What's the difference between detected and actual races? > The output of the drd tool is structured as follows: - First the text "Detected data races. Context:". - Next, four call stacks (start of first segment involved in the race, end of first segment, start of second segment and end of second segment). This information contains the exact thread IDs involved in the data race, and shows the regions of code involved in the data race. There is no exact information on the location of the data race -- I have no idea how to report the exact location in code of a data race without recording a call stack upon each memory access. - Next, the text "Actual data races:" - Next, a list of addresses for which a data race was detected. Each entry in this list contains the following information: * a line with the start address, range size, access pattern by first and second thread (W or R), and how the memory was allocated. * same call stack as the end of the first segment. I would like to suppress this output, but have no idea how this is possible with VG_(maybe_record_error)(). * for dynamically allocated data only, the call stack at the time of allocation of the data (there is no example of this in the output included in my previous E-mail). |