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.
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.
- In Wine:
- In Valgrind:
Valgrind may corrupt the environment; see https://bugs.kde.org/show_bug.cgi?id=215914 (Or is it the shell?)
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:
IBM Rational Purify. See also http://www.ibm.com/software/awdtools/purify/.
Parasoft Insure++. See also http://www.parasoft.com/.
Micro Focus DevPartner BoundsChecker. See also http://www.microfocus.com/products/micro-focus-developer/devpartner/index.aspx.
Deleaker a memory profiler and leak detection tool for C++
Software Verify C++ memory leak detector http://www.softwareverify.com/cpp/memory/index.html
The memory error checker in Intel Parallel Studio. See also http://software.intel.com/en-us/intel-parallel-studio-home/.
MS Application Verifier -- you need to use this anyway to get logo certified
DynamicRio's Dr. Memory -- new, not yet polished, but promising
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).