Fwd: [milter-greylist] HEADS-UP: libspf2 causes milter-greylist memory leak?

Hi,

According to tests done by some people in the milter-greylist community, libspf2
(and possible libspf_alt) causes memory leaks on some OSes. See a cut version
from the posts below:

>On Fri, Oct 24, 2008 at 02:07:58AM +0900, Hajimu UMEMOTO wrote:
>>>>>> On Thu, 23 Oct 2008 14:31:15 +0200
>>>>>> Petar Bogdanovic <[email protected]> said:
>
> petar> The situation even got worse with libspf2 from another point of view
> petar> -- milter-greylist using libspf_alt claimed about 15% of the CPU when
> petar> it had to deal with 900 simultaneous connections while the same
> petar> situation ate every second of the available CPU-time when linked
> petar> against libspf2. That's why I wasn't able to drop the same amounth
> petar> of mails through milter-greylist+libspf2: the CPU was the
> petar> bottleneck.
>
>> The BIND9's resolver requires res_ndestroy() for cleanup res_state.
>> However, libspf2 doesn't issue res_ndestroy() but issues res_nclose().
>> It causes memory leak. The FreeBSD port of libspf2 has a patch to
>> address this issue.
>
>Thanks, I applied all patches (~10) from the FreeBSD Ports tree and the
>problem is gone. The memory usage of milter-greylist is actually frozen
>now, no matter how hard I try. Also, the claimed cpu-time is much lower.

This has been fixed by a patch in the FreeBSD Ports tree. See (and specifically
patch submission [2]):
ftp://ftp.freebsd.org/pub/FreeBSD/development/FreeBSD-CVS/ports/mail/libspf2/files/patch-src_libspf2_spf__dns__resolv.c,v

AFAICS, this fix doesn't seem to be in the latest version of the libspf2-1.2.8
source. Maybe someone can add it to libspf2's main CVS branch instead?

(Someone mentioned that this also seems to be the case in the older (and perhaps
unmaintained libspf_alt, but I don't know if anyone cared to test that).

Regards,
Fredrik