Implementing FLG_HEAP_ENABLE_TAIL_CHECK

Dan Kegel dank at kegel.com
Sat Nov 14 21:17:56 CST 2009


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



More information about the wine-devel mailing list