Monthly Archives: May 2009

Valgrind on Windows?

With the Valgrind-on-Mac support coming along nicely, it’s worth addressing another widely-used platform:  Windows.  Will Valgrind work on Windows any time soon?  There are actually two answers:  (a) hell no, and (b) it already does (sort of).

The patch I merged from the Darwin branch onto the trunk yesterday was 28,300 lines.  And that was almost entirely new code, because I’d done a lot of work to synchronize the branch and trunk so that all non-addition changes had been dealt with.  Greg Parker spent over four years, off and on, working on the original port, and I spent close to three months full time cleaning it up, and Julian Seward also pitched in a bit.  I roughly estimate the Darwin port represents at least 1,000 person-hours of work, possibly much more.

And Mac OS X is a lot closer to Linux than Windows is.  Also, the Mac OS X kernel is open source, which makes a port much easier.  A Valgrind-on-Windows port would therefore be an enormous undertaking, one that is unlikely to happen soon, if ever.  That is how we get answer (a) above.

However, although Valgrind doesn’t run on Windows, it is possible to run Windows programs under Valgrind, thanks to Wine — you run the Windows program under Wine, and Wine under Valgrind.  The development (trunk) versions of both Valgrind and Wine now have enough awareness of each other that they can apparently be used together.  I say “apparently” because I haven’t tried it myself, but I know that others have had some success.  But please note that this is fairly new and experimental, and should only be tried by those not afraid to get their hands dirty (this page has more details). And that’s how we get the answer (b) above.

Mac OS X now supported on the Valgrind trunk

This morning I merged the DARWIN branch, which had been holding Valgrind’s support for Mac OS X, onto the trunk. The branch is now defunct, and Valgrind-on-Mac users should check out the trunk like so:

svn co svn://svn.valgrind.org/valgrind/trunk <dirname>
cd <dirname>

and then build it according to the instructions in the README file.

This is a good thing, if only because it means I can spend less time maintaining a branch and more time actually fixing things.

Update: fixed the svn URL.

Valgrind + Mac OS X update (May 18, 2009)

It’s time for the May update on the progress of the Mac OS X port of Valgrind. In the last month, 133 commits have been made to the DARWIN branch by Julian Seward and myself.

Here are the current (as of r9898) values of the metrics I have been using as a means of tracking progress.

  • The number of regression test failures on Mac was 418/128/43/0. It’s now 421/102/15/0.  I.e. the number of failures went from 171 to 117.  If we ignore the tools Helgrind, DRD and exp-Ptrcheck (which are not widely used and still mostly broken on the branch) the number of failures dropped from 50 to 13.  That’s a similar number to what we get on some Linux systems, and we’re in real diminishing-returns territory — the failing tests are all testing very obscure things.  So we can basically declare victory on that front.
  • The number of “FIXME”-style marker comments that indicate something in the code that needs to be fixed was 274.  It’s now 260.  Furthermore, the method I used last month to count “FIXME”-style comments was flawed, so the number has actually gone down by more than 14;  the comparison next month will be reliable.  But a lot of these comments are for very obscure things that won’t need to be fixed even before a release, so you shouldn’t be worried by the high number!

Functionality improvements from the last month are as follows.

  • Some extra system calls are handled.
  • Some more signal-handling improvements.
  • Some debug info reading improvements.
  • File descriptor tracking (–track-fds) now works.
  • The –auto-run-dsymutil option was added.  When used, it makes Valgrind run dsymutil to generate debug info for any files that need it.
  • Helgrind sort of works;  some of its tests pass.  But it’s still probably not usable.

Things are going well enough that we should be ready to merge the branch to the trunk soon!  That will be a significant milestone, and will make life easier as I won’t have to maintain the branch in parallel with the trunk.  I’m currently going through the branch/trunk differences carefully in order to get ready for the merged, with luck it will happen by the end of this week.

Update, March 19: fixed some HTML tags.