There is a bug somewhere in CentOS 6 that causes Valgrind to report a 24-byte fixed-size leak when MaraDNS is compiled with '-O2'; since the leak goes away when MaraDNS is compiled with '-g', it's an error with the compiler and/or Valgrind.
I'm not going to waste time chasing ghosts that change with different compiler flags.
I have added a couple of documents to the MaraDNS tarball: TESTING.PROCEDURE, which describes how to compile and run MaraDNS so it passes all SQA regressions in CentOS 6, as well as README.malloc, which spells out how MaraDNS and Deadwood act on systems where malloc() fails. If anyone wishes MaraDNS/Deadwood to handle malloc differently, show me the money and we will talk. I would need a five-figure sum (in US dollars or Euros) on the table to even consider looking at the issue.
The point being, the next MaraDNS release is supported on any RHEL6-compatible clone of Linux. Right now, I develop it on CentOS 6, but that can become Oracle Linux 6 or Scientific Linux 6 depending on which RHEL clone is most up-to-date with security fixes.
I am no longer using Windows XP and will change the official version of Windows supported to be Windows 7 when I make my Deadwood release next month.
I have updated the operating systems MaraDNS supports in 2012; I will not update them again until 2017 (both RHEL6 and Windows 7 will be supported by their vendors until 2020).
I plan to work on MaraDNS/Deadwood again one day next month (September), after the 20th, unless a critical security bug with a CVE number is found.
Previous entry Next entry Blog index