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

Hannah Schroeter <[email protected]> Tue, 28 Oct 2008 14:27:28 +0100
Newsgroups gmane.mail.spam.spf.devel
Organization Schlund + Partner AG
Message-ID <[email protected]>
Hi!

On Tue, Oct 28, 2008 at 03:15:20AM +0100, Johann E. Klasek wrote:
>On Sat, Oct 25, 2008 at 01:48:32AM +0900, Hajimu UMEMOTO wrote:
>> >>>>> On Fri, 24 Oct 2008 18:02:36 +0200
>> >>>>> Fredrik Pettai <[email protected]> said:

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

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

>> Here is a patch against 1.2.8:

>> Index: src/libspf2/spf_dns_resolv.c
>> diff -u -p src/libspf2/spf_dns_resolv.c.orig src/libspf2/spf_dns_resolv.c
>> --- src/libspf2/spf_dns_resolv.c.orig	Thu Oct 16 07:02:03 2008
>> +++ src/libspf2/spf_dns_resolv.c	Fri Oct 24 12:19:29 2008
>> @@ -92,7 +92,11 @@ static pthread_key_t	res_state_key;
>>  static void
>>  SPF_dns_resolv_thread_term(void *arg)
>>  {
>> +#ifdef res_ndestroy
>> +	res_ndestroy( (struct __res_state *)arg );
>> +#else
>>  	res_nclose( (struct __res_state *)arg );
>> +#endif
>>  	free(arg);
>>  }

>> @@ -615,7 +619,7 @@ SPF_dns_resolv_new(SPF_dns_server_t *lay
>>  #if HAVE_DECL_RES_NINIT
>>  	pthread_once(&res_state_control, SPF_dns_resolv_init_key);
>>  #else
>> -	if ( res_init() != 0 ) {
>> +	if ((_res.options & RES_INIT) == 0 && res_init() != 0) {
>>  		perror("res_init");
>>  		return NULL;
>>  	}

>Sorry, but this patch won't work on platform where res_* functions are
>real library functions, e.g on Solaris at least up to Solaris 9 ... The
>above fix is targeting mainly Linux or maybe NetBSD where res_* is just
>a macro layer. Even with checking the __RES macro value (resolver
>release date) this could not be catched (e.g. Solaris 9 has
>res_ndestroy, Solaris 8 not but both have the same __RES value!).

>AFIAK some autoconf stuff is needed to get the information if 
>res_ndestroy can (should) be used!

Makes sense.

>Johann Klasek

Kind regards,

Hannah.