It’s been a month since I first wrote about my work on the Mac OS X port of Valgrind. In that time I’ve made 85 commits to the DARWIN branch (and a similar number to the trunk).
Here are the current (as of r9192) values of the metrics I defined in the first post as a means of tracking progress.
- The number of regression test failures on Linux was: 477 tests, 220 stderr failures, 53 stdout failures, 25 post failures (which I’ll abbreviate as 477/220/53/25). It’s now 484/4/1/0. I.e. the number of failures went from 298 to 5. A few new tests have been added. Four of the failures are in Helgrind, the data race detector tool, which I haven’t tracked down yet. The other failure is one that also occurs on the trunk. So almost all the Linux functionality broken by the changes has been restored.
- The number of regression test failures on Mac was 419/293/58/29. It’s now 402/213/52/0. I.e. the number of failures went from 380 to 265. The total number of tests has gone down because some Linux-specific tests are no longer being (inappropriately) run on Mac. This is the most important metric, and it’s improving steadily, but there’s still a long way to go.
- The number of compiler warnings on Linux was 186. It’s now 10, and all of these are from #warning declarations that mark places where improvement need to be made to the Darwin port, but aren’t actually a problem for Linux. The number of compiler warnings on Mac was 461. It’s now 44. Of these, 33 are from #warning declarations, and 10 are from code generated by the Darwin ‘mig’ utility which I have no control over. So compiler warnings aren’t an issue any more, and I won’t bother tracking them as a metric in the future.
- The size of the diff between the trunk and the branch was 55,852 lines (1.9MB). It’s now 41,895 lines (1.5MB). But note that this is not a very useful metric; progress will usually cause it to drop, but it will also increase as missing Darwin functionality is added.
Interestingly enough, although this number of Mac test failures has gone down significantly, if the branch didn’t handle your program a month ago it probably still won’t handle it now (although getsockopt() no longer causes an abort). But Valgrind’s output may well be better (e.g. debugging information will be better utilized). Much of my effort has been in making the tests pass — improving cases where the Darwin port was doing basically the right thing, but its output didn’t exactly match that expected.
One example is that stack traces were a little unclean, in various minor ways. Another example is that I added a –ignore-fn option to Massif (the heap profiler) which allows it to ignore certain heap allocations. This was required because Darwin’s libc always does a few heap allocations at start-up, but Linux’s libc doesn’t. The new option allows the Darwin allocations to be ignored and therefore Massif’s output to be consistent on both platforms.
Few if any of these changes have made the branch closer to handling new programs, at least directly. But there’s no point apologising about this, because the branch won’t reach a highly functional state without a working test suite to serve as a safety net against regressions. And as I progress, getting more tests to pass will require genuine new program functionality to be supported, so improvements should start to occur on that front soon. For example, signals currently aren’t supported at all, and this is why Firefox does not run under Valgrind on Mac yet — all calls to sigaction() currently return -1, which causes an assertion failure somewhere in NSPR.
Something else worth mentioning: I bought a new MacBook Pro, as my old 32-bit only was was slow and noisy and getting annoying. The new machine is 64-bit capable, but compiles to 32-bit by default and Valgrind’s configure script identifies it as a 32-bit only machine. If anybody knows how to make configure recognise that it’s a 64-bit machine I’d love to hear about it.
Update, March 17: fixed a broken link to an earlier post.
