Wine and Valgrind

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. It's useful for debugging wine itself, as well as windows apps running on Wine. (See "Debugging Mozilla with Valgrind")

You need Valgrind 3.8.0 or newer to avoid valgrind bug 275673.

To make Wine play properly with valgrind, you need to build Wine yourself after installing Valgrind; see "Building Wine" below.

To ignore errors not due to Wine, you can use suppression files that AustinEnglish has put together. They are available, along with scripts for running wine's tests under valgrind here

Building Wine

Install Valgrind first, since Wine needs Valgrind's include files.

Configure Wine as normal, but use CFLAGS="-g -O0". (This will slow Wine down slightly, but give better stacks.)

Check that Wine found Valgrind's header files by doing

grep VALGRIND include/config.h

If that doesn't show

#define HAVE_VALGRIND_MEMCHECK_H 1 
#define HAVE_VALGRIND_VALGRIND_H 1

then something went wrong.

Then build Wine as usual with make.

Additional Wine patches

There are a few patches on Bugzilla that may be useful: * clear slots in new argv[] - https://bugs.winehq.org/show_bug.cgi?id=14359 * co-operate with valgrind at execv - https://bugs.winehq.org/show_bug.cgi?id=14361 * enhance loader and wine_main_preload_info for valgrind - https://bugs.winehq.org/show_bug.cgi?id=14364 * do not touch high address space (initial stack, user_space_limit) - https://bugs.winehq.org/show_bug.cgi?id=14365 * co-operate with valgrind when switching stacks - https://bugs.winehq.org/show_bug.cgi?id=14366 * adjust timeout interval for virtulaizers - https://bugs.winehq.org/show_bug.cgi?id=14370

If you want to use one of Valgrind's thread checking tools DRD or Helgrind, it is strongly recommended to apply the patch attached to http://bugs.winehq.org/show_bug.cgi?id=24164 before building Wine. This patch informs Valgrind's data race detection tools that e.g. EnterCriticalSection() and LeaveCriticalSection() are synchronization primitives and also suppresses several reports about uninteresting conflicting memory accesses in Wine itself. Without this patch both tools will report so much conflicting memory accesses that these tools are unusable.

Running Wine under Valgrind

Because of the way Wine is started, you must use the --trace-children option in valgrind to make it work. To make DIB sections work under valgrind, you must also use --vex-iropt-register-updates=allregs-at-mem-access. To avoid spurious warnings about writing below the stack, you must also use --workaround-gcc296-bugs=yes. For example:

valgrind --trace-children=yes ---vex-iropt-register-updates=allregs-at-mem-access --workaround-gcc296-bugs=yes --suppressions=$HOME/valgrind-suppressions-ignore --suppressions=$HOME/valgrind-suppressions-external 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 (e.g., notepad/winemine), 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.

The need for --vex-iropt-register-updates=allregs-at-mem-access is documented at http://valgrind.org/docs/manual/manual-core-adv.html

Please keep in mind that when analyzing applications built with Microsoft Visual Studio that the debug version of the MSVC runtime library always initializes memory allocated via malloc(). This defeats Valgrind's ability to detect uninitialized memory accesses. See also Memory Management and the Debug Heap for more information.

Controlling Memory Leak logging

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 --trace-children=yes --vex-iropt-register-updates=allregs-at-mem-access --workaround-gcc296-bugs=yes --leak-check=full wine foo.exe

You can make Valgrind ignore less-certain memory leaks with the --show-possibly-lost=no option.

You can make Valgrind give you a stack backtrace of the point where the memory block was allocated, which is terrifically helpful. It also makes valgrind run even slower. If you want this, you have to turn it on with --track-origins=yes.

Known Problems

If you see lots of warnings about invalid four byte reads in the last three bytes of allocations, this may be false positives from vectorized string operations ( see https://bugs.kde.org/show_bug.cgi?id=264936 ); try --partial-loads-ok=yes

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-ignore --suppressions=$HOME/valgrind-suppressions-external --num-callers=20  --workaround-gcc296-bugs=yes --vex-iropt-register-updates=allregs-at-mem-access"
WINETEST_WRAPPER=valgrind make -k test > test.log 2>&1

Tweaking use-after-free and overrun sensitivity

There are two constants in the Wine sources which might be worth tweaking under some circumstances.

MAX_FREE_PENDING controls how long freed blocks are kept out of circulation (this helps detect use-after-free errors). It is currently 1024. If you think your app is hanging on to freed pointers for a long time, you might want to increase that and recompile Wine.

HEAP_TAIL_EXTRA_SIZE gives the size of the redzone at the end of each block. If your app uses an array or struct of really big structs, this might need to be increased to catch overrun errors. (But watch out; increasing it beyond 32 bytes or so caused strange false positives for me.)

Mac OS X support

Valgrind's trunk now supports the Mac; see Mac OS X now supported on the Valgrind trunk - May 28th, 2009 by Nicholas Nethercote /!\ Note: On the mac, if you want line numbers, don't forget to tell xcode to generate a .dSYM file. You can also use gdb after the fact to look up line numbers.

Alternatives that run on Windows

There are a number of similar tools that run on Windows rather than Linux:

That said, Windows developers might well want to run their apps on Wine just to get Valgrind, since Valgrind offers some features those tools don't (not least of which is, it's free, it's fast and it can handle Mac and Linux apps as well).


CategoryQualityAssurance CategoryDevelopment CategoryThirdParty

Wine and Valgrind (last edited 2014-07-09 22:22:15 by AustinEnglish)