Running Chromium's test suite under valgrind+wine did find a handful of interesting Wine problems, and one or two Chromium problems, but it seems to miss a whole bunch of problems Purify catches.
Thinking about it a bit, I realized that Valgrind replaces the linux heap with one that puts guard bytes before and after each allocation, and marks those guard bytes as inaccessible. Valgrind's replacement heap also keeps freed blocks out of circulation for a while, marking them completely inaccessible so that references to freed blocks are caught. At the moment, nothing does this when running win32 apps under wine+valgrind; sure, wine informs Valgrind about the allocations made by the NT heap, but it doesn't put any guard bytes around them.
So, how can we achieve this on Wine? The Wine philosophy is to look for how Windows likes to do things, and sure enough, there are ways to tell the Windows kernel to do similar things. http://technet.microsoft.com/en-us/library/cc736347(WS.10).aspx describes the gflags utility, used to set registry flags that end up controlling the NtGlobalFlags field of each processes' PEB.
FLG_HEAP_ENABLE_TAIL_CHECK tells the heap to add guard bytes at the end of each allocation.
FLG_HEAP_PAGE_ALLOCS tells the heap to add a whole guard page at the end of each allocation. (The /backwards option to gflags modifies this to put the page at the beginning of the allocation, but I don't know what NtGlobalFlags value this corresponds to.)
I don't see any option there for "keep newly freed blocks out of circulation for the moment"; FLG_HEAP_DISABLE_COALESCING is kind of close.
I'm tempted to try implementing enough of this so Wine+Valgrind can catch more of the Chromium errors that Purify can.
Thoughts? - Dan
-
Dan Kegel