the attached patch contains the architecture changes needed to WINE to enable multithreaded processes to be checked by valgrind. It must be applied to a current CVS WINE. part 2 message has several fixes for uninitialized data I have made to the WINE tree - you should also apply this to reduce the number of errors you get a bit! All of these patches work with and without valgrind - maintainers please commit them to the CVS tree! All code in this patch is (c) Cyberscience Corporation, but released under LGPL with NO WARRANTY. you will also need to apply a patch to a valgrind CVS version from: :pserver:anonymous@cvs.sourceforge.net:/cvsroot/valgrind valgrind patch at: http://sourceforge.net/tracker/index.php?func=detail&aid=710006&group_id=46268&atid=445588 with these patches, valgrind can also handle Windows PE/PDB format files, and produce stack traces from them. The architecture changes are needed to allow multiple threads to be controlled by valgrind - valgrind has a 'green' threads implementation, which means there isn't a separate (real) PID for each thread. In order to cope with this the WINE server has been modified to pass back requests to suspend a (local) thread to the client process. The other major (and possibly contentious) change is that I have 'packed' the message structures sent between the client and the server - this is needed because valgrind gives hundreds of errors due to sending uninitialized padding bytes across the connection. These structures are only used for message sending/receiving, so there shouldn't be a performance penalty. Using valgrind with WINE ------------------------ once you have patched valgrind and installed it, then patch a CVS version of WINE, re-run configure and build (in debug mode - ie "CFLAGS=-g ./configure"). you should now have a wrapper script called wine.vg which will run wine under valgrind (you can also install wine and run the binary under valgrind). example: test program notepad.exe wine.vg notepad.exe using the wine.vg script, valgrind will stop at each error, and give you the choice of starting gdb, ignoring the error, or ignoring all further errors. If you start gdb, you can examine variables, look at stack etc. NOTE that gdb doesn't understand PE/PDB, so you won't get function names or line numbers for 'real' Windows parts of the code. you MUST NOT continue the program, or step etc while in gdb - this will NOT WORK. you can only examine the data and stack. to continue, you should quit gdb, then valgrind will resume checking. example test a debug program built under MSVC build the code in "Debug" mode under MSVC. cp /mnt/windows/test.exe . cp /mnt/windows/test.pdb . cp /mnt/windows/atestdll.dll . cp /mnt/windows/atestdll.pdb . possibly also: cp /mnt/windows/.../mfc42.dll . cp /mnt/windows/.../mfc42.pdb . then: wine.vg test.exe Seeya, Adam -- Real Programmers don't comment their code. If it was hard to write, it should be hard to read, and even harder to modify. These are all my own opinions.
Attachment:
wine-valgrind.patch.arch
Description: Binary data
Attachment:
wine-valgrind.clog.arch
Description: Binary data
