I use MacOS X for most of my development work, but part of my job is writing apps that run on all major Unixes and Win32. Most of the time bugs and memleaks are "portable", meaning that they appear on all platforms in the same way and fixing them on your dev-platforms, fixes them everywhere else.
Well, "most of the time".
Today I had the joy of a win32 only mem-leak. We actually ''bisect''ed it down to the locking support for openssl that we just added http://www.openssl.org/docs/crypto/threads.html. But starring at the code didn't reveal anything obvious. So, back to the tools. Let them find it.
Going through the web on the search for "how to find mem-leaks on win32" I came along:
The idea is simple:
- use wine to run the win32 app
- run wine in valgrind
You get all the benefits of valgrind and can work on the OS you are used to. But not so fast:
- wine from MacPorts is 32bit only http://trac.macports.org/browser/trunk/dports/x11/wine-devel/Portfile
... but all your macports (at least on Mac OS X 10.6) dependencies are 64bit only. After rebuilding the dependencies with +universal, wine starts up nicely:
[jan@macbook bin]$ file mysql-proxy.exe mysql-proxy.exe: PE32 executable for MS Windows (console) Intel 80386 32-bit [jan@macbook bin]$ wine mysql-proxy.exe --version mysql-proxy 0.8.0 chassis: mysql-proxy 0.8.0 glib2: 2.20.3 libevent: 1.4.12-stable LUA: Lua 5.1.2 package.path: Z:\Users\jan\projects\in-targz\mysql-monitor-agent-184.108.40.2067-win32-x86\lib package.cpath: Z:\Users\jan\projects\in-targz\mysql-monitor-agent-220.127.116.117-win32-x86\bin\lua-?.dll -- modules admin: 0.7.0 proxy: 0.7.0
- valgrind fails to build as +universal if built from MacPorts http://trac.macports.org/browser/trunk/dports/devel/valgrind-devel/Portfile
... and ends up as 64bit app ... which can't run a 32bit 'wine'. Back to "build valgrind by hand". Using the Portfile as template I set up the valgrind source tree and built it with '--enable-32bitonly' to get a 32bit valgrind.
Everything in place that I need I did hit a bug in valgrind: https://bugs.kde.org/show_bug.cgi?id=194757
Anyway, some real hints how to track down the mem-leaks on win32: