Valgrind (http://www.valgrind.org/) is a set of tools aimed at finding bugs and performance problems in programs. By default, it catches reads of uninitialized memory, accesses to inaccessible memory, and memory leaks.
Valgrind 3.4.0 supports Wine out of the box. However, to make Wine play properly with valgrind, you need to build Wine yourself after installing valgrind Also, to ignore errors not due to Wine, you will want to use the Valgrind suppressions file Dan Kegel has put together.
You probably need valgrind from svn to get pdb support, but you'll need a workaround (see "Building Valgrind" below). You probably also want the tail check patch when building wine (see below). Also, some of John Reiser's patches are still not merged, it's possible some of them are needed (see "Heap Tail Check" below).
Valgrind's trunk now supports the Mac; see Mac OS X now supported on the Valgrind trunk - May 28th, 2009 by Nicholas Nethercote ![/!\](/wiki/winehq/img/alert.png "/!\"){kind=small}
Note: On the mac, if you want line numbers, don't forget to tell xcode to generate a .dSYM file.
Contents
Running Wine under Valgrind
The standard stuff
Because of the way Wine is started, you must use the --trace-children option in valgrind to make it work. For example:
valgrind --trace-children=yes wine foo.exe
Note that this command will also trace the wineserver if this is the first Wine application running. As Valgrind is pretty intensive on CPU, you can speed things up quite a bit by not running the wineserver under Valgrind. Here's the way to do it: 1/ start a dummy program under Wine (I like winemine, pick up your own), 2/ start valgrind for wine as you would normally do.
The wineserver will be started by step 1/, not 2/ and won't be run under Valgrind.
Memory leak
Valgrind by default will give you a count of memory leaks at the end of the run. To get more info, add the --leak-check=full flag when running Valgrind, e.g.
valgrind --tool=memcheck --trace-children=yes --leak-check=full wine foo.exe
You'll likely get some generic leak errors: for module loading (some modules are not unloaded, and some glibc version leak memory in dlopen:ed libraries), and wine's X11 drivers loading (the thread data structure is not free upon last thread exit). You can safely ignore those.
Origin Tracking
In errors about memory blocks, Valgrind can give you a stack backtrace of the point where the memory block was allocated, which is terrificly helpful. It also makes valgrind run even slower. If you want this, you have to turn it on with --track-origins=yes.
Building Valgrind
If you don't have automake and autoconf installed, install them first, e.g. with 'sudo apt-get install automake autoconf'.
Here's an automated script that builds valgrind with the appropriate patches:
svn checkout http://winezeug.googlecode.com/svn/trunk/ winezeug cd winezeug/valgrind sh build-valgrind-for-wine.sh
This puts valgrind in /usr/local/valgrind-10880/bin/valgrind.
Below are the original manual instructions for doing the same thing.
Here's how to build Valgrind from fresh svn source:
svn co svn://svn.valgrind.org/valgrind/trunk valgrind cd valgrind wget -O mprotect.patch "http://bugsfiles.kde.org/attachment.cgi?id=36564" patch -p0 < mprotect.patch sh autogen.sh ./configure --prefix=/usr/local/valgrind-svn make sudo make install # Then, optionally, if your system's valgrind include headers are too old: sudo mv /usr/include/valgrind /usr/include/valgrind.old sudo ln -s /usr/local/valgrind-svn/include/valgrind /usr/include
The mprotect patch mentioned above is a workaround for http://bugs.winehq.org/show_bug.cgi?id=20303 which was introduced when Mac support was merged into the Valgrind tree. Vote for https://bugs.kde.org/show_bug.cgi?id=205541 if you want to encourage the valgrind developers to fix this.
You may also want to apply http://bugsfiles.kde.org/attachment.cgi?id=38212 to add support for the --show-possible option to reduce the number of false positive memory leak reports; see https://bugs.kde.org/show_bug.cgi?id=201170.
I usually do "svn info" to find out the revision number rrrrr of valgrind, then install it into /usr/local/valgrind-rrrrr. That way I can have multiple copies installed if I need it.
Don't link valgrind with binutils.gold; it won't work. You currently have to use plain old binutils.
Heap Tail Check
It turns out that Wine's heap wasn't instrumented sufficiently to give best results with valgrind. One problem was that Wine wasn't leaving an inaccessible redzone after each allocation. Dan Kegel has an experimental patch to add this: part 1 part 2. You'll then need to set WINE_HEAP_REDZONE=16 to enable this feature.
This is still being polished; Dan hopes to get it into the main tree soon.
Running Application tests under Valgrind+wine
See http://winezeug.googlecode.com/svn/trunk/valgrind/doc/win32.html for a draft article about running a win32 application's test suite under valgrind+wine.
Running Wine's conformance tests under Valgrind
To run Wine tests under Valgrind, set the WINETEST_WRAPPER and VALGRIND_OPTS variables, e.g.
export VALGRIND_OPTS="--trace-children=yes --track-origins=yes --gen-suppressions=all --suppressions=$HOME/valgrind-suppressions --leak-check=full --num-callers=20 --workaround-gcc296-bugs=yes" PATH=/usr/local/valgrind-svn/bin:$PATH WINETEST_WRAPPER=valgrind make -k test > test.log 2>&1
That --suppressions=$HOME/valgrind-suppressions refers to the following file, which you have to download separately:
It suppresses warnings known to be bogus, not Wine's fault, or too hard to deal with for now.
If you see lots of spurious errors (e.g. in ld.so or Xlib) just copy the suppressions from the log file into valgrind-suppressions and rerun. If that helped, please email your new suppressions file to dank@kegel.com, and I'll update my copy.
See also MakeTestFailures for some tips on how to set up your system to reduce test failures.
It's a good idea to delete ~/.wine before running tests, just in case you've installed some app that interferes with them somehow (e.g. iTunes).
Here's an example script to build and run the whole test suite under Valgrind, and split up the results:
Here's a script that splits valgrind log files up by wine test:
This puts the warnings from e.g. comctl32/tests/listview.c into the file vg-comctl32_listview.txt.
Tip: compile Wine with -O1
Valgrind provides much better information if you compile wine without inlining. To do this, change -O2 to -O1 in Wine's Makefiles. The easiest way to do this for the whole tree is to override CFLAGS when configuring Wine, e.g.
./configure CFLAGS="-g -O1" make depend && make
Lowering the optimization level also reveals some errors that are suppressed in optimized builds, and might suppress a few errors accidentally. Overall it's a win. (And if you don't mind slower runtime, disabling all optimizations using -O0 instead of -O1 builds Wine nearly twice as fast and may provide even better stack traces.)
Tip: flush out warnings quicker with WINEDEBUG
Valgrind doesn't warn when uninitialised values are simply passed from one place to another; it only warns when they're used to make some decision or produce some output. If you're tracking down a particular warning, you might find it helpful to print out the values involved just to force Valgrind to show you whether they're defined. One easy way to do this is to look at the source files involved for TRACE() statements that already print out the variables of interest. If there are any, you can activate them by setting the environment variable WINEDEBUG=+foo or WINEDEBUG=+foo,+bar, where foo and bar are the argument to the macro WINE_DEFAULT_DEBUG_CHANNEL at the top of the involved source files. So for example, if you're tracking down a warning in test_profile_existing() in kernel32/tests/profile.c, you would look at the top of kernel32/profile.c, see the line WINE_DEFAULT_DEBUG_CHANNEL(profile), and rerun that file's tests with
cd dlls/kernel32/tests WINEDEBUG=+profile RUNTEST_USE_VALGRIND=1 ../../../tools/runtest -P wine -M kernel32.dll -T ../../.. -p kernel32_test.exe.so profile.c > log 2>&1
That will trigger the TRACE() calls in kernel32/profile.c. Oh, boy will it ever. Sometimes it's a bit overwhelming. In theory, we'd want to fix all the extra Valgrind warnings this produces, but in practice, just grit your teeth and ignore the extra new messages not related to the problem you're tracking down.
Test results
See http://kegel.com/wine/valgrind/ for Dan Kegel's Valgrind logs from running the entire wine test suite.
What remains to be fixed in Valgrind & Wine
A few bugs are noted in valgrind's bug tracker, see http://bugs.winehq.org/buglist.cgi?quicksearch=valgrind
- John Reiser's patchset did quite a few things, some of which never made it into valgrind's trunk. It's possible we still need some of them. He has filed bugs for some of them.