|
From: Bart V. A. <bar...@gm...> - 2006-08-23 20:04:59
|
On 8/23/06, Julian Seward <js...@ac...> wrote: > > > > I have done some tests, and the huge memory consumption is probably due > to > > a memory leak when doing segment deallocation. > > It would probably help if you allocated the bitmaps using > VG_(am_shadow_alloc) rather than VG_(malloc). (grep for > examples of usage). This reduces the extent to which client and > shadow address spaces are interleaved. > One problem with VG_(am_shadow_alloc) is you can't then free the > result (ever); but you could put "freed" bitmaps on a freelist > and first allocate from there. Does that make sense? It's > worth a try. Can you try it? As soon as I have time, but I don't have that much spare time currently :-( > > Before I can say something about the memory use of drd, I have to > > explain its algorithm. In short, the data race detection algorithm works > as > > follows: [...] > > It helps, but (1) it still does not define the terms "detected race" > and "actual race", and (2) you also need to say what a vector clock is. > The actual text in the output is "Detected data races.", which is short for "The drd tool detected some data races". Each time the drd tool detects data races, it prints the following chunks of information: - call stack of segment begin and end in the first involved thread. - call stack of segment begin and end in the second involved thread. - 32-bit addresses in the client address space of the data involved in the race. Above this last section the text "Actual race" is printed. Maybe I should change this in "Addresses of detected data races" ? Regarding vector clocks: is the following Wiki clear enough ? http://en.wikipedia.org/wiki/Vector_clocks In the diagram A, B and C correspond to threads. |