Dr. Memory is a new open-source tool for finding memory errors - similar to Memcheck (Valgrind) but with Windows support, including detection of Windows handle leaks and GDI usage errors.

Dr. Memory is running on the MFYI waterfall MFYI waterfall where it finds bugs in Chromium on Windows.

If you want to try Dr. Memory on your machine, please do the following:

First of all, you need Windows. Win7 x64 is preferred. DrMemory supports Linux, but the support is not as robust.

Build Chromium tests on Windows in either Release or Debug configuration (you can save some time by building only the small tests like googleurl, ipc, base, net to start with). Release runs faster. For either Release or Debug, build with the following setting in order to disable inlining and FPO for better callstacks by placing this in your ~/.gyp/include.gypi file:

{

'variables': {

'build_for_tool': 'drmemory',

},}

or set GYP_DEFINES=build_for_tool=drmemory gclient runhooks

The Dr. Memory binaries are downloaded from Google Storage automatically (on Windows) into the third_party/drmemory directory.

Now you can run chromium tests like this:tools\valgrind\chrome_tests.bat -t <test> --tool drmemory_light # only search for unaddressable accesses and uses-after-freeortools\valgrind\chrome_tests.bat -t <test> --tool drmemory_full # search for uninits and leaks etc as wellAlternatively, if you prefer Cygwin, you can also use tools/valgrind/chrome_tests.sh with the same arguments. Just be aware that the bots use the .bat script.

You can use --build-dir to select between Debug and Release, for example: tools\valgrind\chrome_tests.bat -t base_unittests --tool drmemory_light --build-dir=out\Release

It will print you some error reports at the end.

If for some reason you cannot reproduce a bot failure on your Windows machine, look for the exact command that started the tests and run that. For example, here is one variation of the test command that catches some memory bugs that the above commands may not catch:

drmemory_light vs drmemory_full

Full: additionally searches for uninitialized reads but adds a large slowdown.

More on the "full" mode:

If you're familiar with the Valgrind guts you probably know that tools like Valgrind and Dr. Memory need to intercept and handle all system calls to know precisely what data is uninitialized, what is read and so on.

In contrast to the open-source Linux kernel with just a hundred system calls or so, on Windows we have an open-ended problem of handling undocumented system calls.We're trying hard to do that but we haven't finished yet. We have some heuristics that work pretty well to ignore errors stemming from system libraries making system calls as opposed to Chromium code, but if you do see an error report that you believe is a false positive, please create a short reproducer and file it into our issue tracker.

Suppressing error reports from the bots

TODO(rnk): When the DrMemory bots have moved to the chromium.memory.fyi waterfall, this information will be moved into the memory sheriff page.

timurrrr: most of this info sounds DrMemory-specific, do we really want to put it onto the "common" page?

The DrMemory suppression file is at tools/valgrind/drmemory/suppressions[_full].txt.Generally speaking, suppressions in these files are maintained in exactly the same way as those for all of the other memory tools we use for Chromium, except that DrMemory uses a slightly different suppression format.

When the bot generates a report, follow the link to the bot's stdio and search for "hash=#" to find the report quickly. You should see something similar to:

As a starting point, you can copy the suppression (the portion between the curly brackets not including the brackets) into the suppressions.txt file and then widen it so it covers any similar reports on other bots.The curly brackets are not part of the suppression as in all the other memory tools! DrMemory suppressions are separated by blank lines instead, so make sure your suppression does not run into an existing suppression.

Each frame from the stack trace is of the form "<module>!<function>". For functions from Chrome, we generally link the code statically into many different binaries, so we always use a wildcard for the module.For third party code, it is generally helpful to identify which DLL the frame came from, especially since we often do not have debug info for windows system libraries.

As in the other tool suppression formats, '*' is a single frame variable-width wildcard, '?' is a single-character wildcard, and '...' will match any number of frames.

DrMemory has support for a handful of other pattern matching mechanisms.In particular, if you paste the instruction from the report on a line starting with "instruction=", you can match the exact instruction producing the report.The instruction= qualifier is mostly useful when suppressing bit-level false positive uninitialized reads in third party libraries where we don't have an accurate callstack and want to make a tight suppression.

Once you have your suppression, you can test that it suppresses the existing reports using tools/valgrind/waterfall.sh as you would with the other memory tools.

Running Chromium under Dr. Memory on a given set of URLs

First, put the list of URLs into tools\valgrind\reliability\url_list.txt, one URL per line without the http:// prefix. You can also put in the local URLs like file://c:\mypath\repro.htm

Running your custom command line under Dr. Memory

Sometimes you may need to run your own program or your own custom command line under Dr. Memory. For example, if you want to prefix your own "chrome.exe --my-flags" command with Dr. Memory, do the following:tools\valgrind\drmemory.bat chrome.exe -- --my-flags # don't forget to increase the timeoutsIf the command line runs Chrome, you may consider increasing the timeouts by appending