Milter-greylist

Using libspf2 with milter-greylist 4.0 on a Fedora Core 6 machine
causes the milter to crash within a couple of minutes. Before that
time, it is fully functional. Without spf support (nospf), the system
is does not crash

The issue does not seem to be related to thread safety issues of the
dns resolver.

When installing the exact same binaries (through rpm builds) on a
Pentium machine running Fedora 7, milter-greylist is stable even when
enabling spf.

The machine that milter-greylist crashes on is based on a 32 bit
Athlon processor.

Any ideas?

On Fri, 14 Mar 2008 17:19:06 -0000 reschauzier <reschauzier@...> wrote:

> Using libspf2 with milter-greylist 4.0 on a Fedora Core 6 machine
> causes the milter to crash within a couple of minutes. Before that
> time, it is fully functional. Without spf support (nospf), the system
> is does not crash
> 
> When installing the exact same binaries (through rpm builds) on a
> Pentium machine running Fedora 7, milter-greylist is stable even when
> enabling spf.
> 
> Any ideas?

Please provide gdb backtrace.

Regards,
Nerijus

On Fri, Mar 14, 2008 at 05:19:06PM -0000, reschauzier wrote:
> Using libspf2 with milter-greylist 4.0 on a Fedora Core 6 machine
> causes the milter to crash within a couple of minutes. Before that
> time, it is fully functional. Without spf support (nospf), the system
> is does not crash
> 
> The issue does not seem to be related to thread safety issues of the
> dns resolver.

On 64bit systems there is a data type (int/size_t mismatch) problem ...
(beside some others). But you stated below, its a 32bit system?
Depending on the traffic volume, milter-greylist crashes after some seconds
rather than minutes, if this issue would responsible for that.

Look at http://jk.kom.tuwien.ac.at/software/milter-greylist/ down to libspf2
(to be find on http://milter-greylist.wikidot.com soon - hope so ;) ).

> 
> When installing the exact same binaries (through rpm builds) on a
> Pentium machine running Fedora 7, milter-greylist is stable even when
> enabling spf.
> 
> The machine that milter-greylist crashes on is based on a 32 bit
> Athlon processor.
> 
> Any ideas?
> 

If this is not related to a the 64bit issue, I suggest to check the
res_ninit-patch anyway. So far I had only problems on Solaris 8/Sparc
systems with the bind8-resolver (but not on Linux FC 6/64bit).

The malloc issue mentioned at my site should only substantial if
memory is getting short ...

Enable core dumping and save some for later analysis :)


Johann K.

See below. Let me know if you need additional info.

Rudy.

Core was generated by `/usr/bin/milter-greylist -P
/var/milter-greylist/milter-greylist.pid -p /var/mi'.
Program terminated with signal 11, Segmentation fault.
#0  0x00c75f6c in free () from /lib/libc.so.6
(gdb)     thread apply all bt full

Thread 5 (process 13693):
#0  0x00110402 in __kernel_vsyscall ()
No symbol table info available.
#1  0x00cd3041 in select () from /lib/libc.so.6
No symbol table info available.
#2  0x08063630 in pclose ()
No symbol table info available.
#3  0x0806246c in pclose ()
No symbol table info available.
#4  0x0804ea6a in pclose ()
No symbol table info available.
#5  0x00c21dec in __libc_start_main () from /lib/libc.so.6
No symbol table info available.
#6  0x0804a691 in pclose ()
No symbol table info available.

Thread 4 (process 13694):
#0  0x00110402 in __kernel_vsyscall ()
No symbol table info available.
#1  0x00dba4dc in pthread_cond_timedwait@@GLIBC_2.3.2 () from
/lib/libpthread.so.0
No symbol table info available.
#2  0x0805d5fb in pclose ()
---Type <return> to continue, or q <return> to quit---
No symbol table info available.
#3  0x00db645b in start_thread () from /lib/libpthread.so.0
No symbol table info available.
#4  0x00cda23e in clone () from /lib/libc.so.6
No symbol table info available.

Thread 3 (process 13695):
#0  0x00110402 in __kernel_vsyscall ()
No symbol table info available.
#1  0x00dba256 in pthread_cond_wait@@GLIBC_2.3.2 () from
/lib/libpthread.so.0
No symbol table info available.
#2  0x08053458 in pclose ()
No symbol table info available.
#3  0x00db645b in start_thread () from /lib/libpthread.so.0
No symbol table info available.
#4  0x00cda23e in clone () from /lib/libc.so.6
No symbol table info available.

Thread 2 (process 13696):
#0  0x00110402 in __kernel_vsyscall ()
No symbol table info available.
#1  0x00dbdf6e in do_sigwait () from /lib/libpthread.so.0
No symbol table info available.
---Type <return> to continue, or q <return> to quit---
#2  0x00dbe00f in sigwait () from /lib/libpthread.so.0
No symbol table info available.
#3  0x08065509 in pclose ()
No symbol table info available.
#4  0x00db645b in start_thread () from /lib/libpthread.so.0
No symbol table info available.
#5  0x00cda23e in clone () from /lib/libc.so.6
No symbol table info available.

Thread 1 (process 13734):
#0  0x00c75f6c in free () from /lib/libc.so.6
No symbol table info available.
#1  0x0014ae74 in __res_ndestroy () from /usr/lib/libbind.so.4
No symbol table info available.
#2  0x0014b7ee in __res_vinit () from /usr/lib/libbind.so.4
No symbol table info available.
#3  0x0014c4f5 in __res_ninit () from /usr/lib/libbind.so.4
No symbol table info available.
#4  0x00a71f9c in SPF_dns_resolv_new () from /usr/lib/libspf2.so.2
No symbol table info available.
#5  0x00a7003f in SPF_dns_lookup () from /usr/lib/libspf2.so.2
No symbol table info available.
#6  0x00a709b2 in SPF_dns_get_client_dom () from /usr/lib/libspf2.so.2
---Type <return> to continue, or q <return> to quit---
No symbol table info available.
#7  0x00a7003f in SPF_dns_lookup () from /usr/lib/libspf2.so.2
No symbol table info available.
#8  0x00a7916f in SPF_server_get_record () from /usr/lib/libspf2.so.2
No symbol table info available.
#9  0x00a785c3 in SPF_request_query_mailfrom () from /usr/lib/libspf2.so.2
No symbol table info available.
#10 0x0805da65 in pclose ()
No symbol table info available.
#11 0x0804dd7a in pclose ()
No symbol table info available.
#12 0x08066437 in freehostent ()
No symbol table info available.
#13 0x080674b7 in freehostent ()
No symbol table info available.
#14 0x08063f78 in pclose ()
No symbol table info available.
#15 0x0806275d in pclose ()
No symbol table info available.
#16 0x00db645b in start_thread () from /lib/libpthread.so.0
No symbol table info available.
#17 0x00cda23e in clone () from /lib/libc.so.6
No symbol table info available.



--- In milter-greylist@yahoogroups.com, Nerijus Baliunas <nerijus@...>
wrote:

>
> On Fri, 14 Mar 2008 17:19:06 -0000 reschauzier <reschauzier@...> wrote:
> 
> > Using libspf2 with milter-greylist 4.0 on a Fedora Core 6 machine
> > causes the milter to crash within a couple of minutes. Before that
> > time, it is fully functional. Without spf support (nospf), the system
> > is does not crash
> > 
> > When installing the exact same binaries (through rpm builds) on a
> > Pentium machine running Fedora 7, milter-greylist is stable even when
> > enabling spf.
> > 
> > Any ideas?
> 
> Please provide gdb backtrace.
> 
> Regards,
> Nerijus
>

On Fri, Mar 14, 2008 at 09:39:32PM -0000, reschauzier wrote:
> See below. Let me know if you need additional info.
> 
> Rudy.
> 
> Core was generated by `/usr/bin/milter-greylist -P
> /var/milter-greylist/milter-greylist.pid -p /var/mi'.
> Program terminated with signal 11, Segmentation fault.
> #0  0x00c75f6c in free () from /lib/libc.so.6
> (gdb)     thread apply all bt full
> 
[..]
> 
> Thread 1 (process 13734):
> #0  0x00c75f6c in free () from /lib/libc.so.6
> No symbol table info available.
> #1  0x0014ae74 in __res_ndestroy () from /usr/lib/libbind.so.4
> No symbol table info available.
> #2  0x0014b7ee in __res_vinit () from /usr/lib/libbind.so.4
> No symbol table info available.
> #3  0x0014c4f5 in __res_ninit () from /usr/lib/libbind.so.4
> No symbol table info available.
> #4  0x00a71f9c in SPF_dns_resolv_new () from /usr/lib/libspf2.so.2
> No symbol table info available.
> #5  0x00a7003f in SPF_dns_lookup () from /usr/lib/libspf2.so.2
> No symbol table info available.
> #6  0x00a709b2 in SPF_dns_get_client_dom () from /usr/lib/libspf2.so.2
> ---Type <return> to continue, or q <return> to quit---
> No symbol table info available.
> #7  0x00a7003f in SPF_dns_lookup () from /usr/lib/libspf2.so.2
> No symbol table info available.
> #8  0x00a7916f in SPF_server_get_record () from /usr/lib/libspf2.so.2
> No symbol table info available.
> #9  0x00a785c3 in SPF_request_query_mailfrom () from /usr/lib/libspf2.so.2
> No symbol table info available.
[..]

This seems really to be the known res_ninit() issue (see my previous
posting): The caller have to provide a private data segment, for
subsequent resolver calls. If this memory area will be not cleared, some
resolver-library versions are assuming non-zero values of the data
structure as pointer to not returned malloc'd memory from the past - but
this assumption is wrong if the malloc'd memory was not wiped with zeros
and garbage is in the memory segment. Trying to apply free on such a
surious pointer leads to a segmentation fault (sooner or later).

Hope this helps.

Johann K.

On Fri, 14 Mar 2008 21:39:32 -0000 reschauzier <reschauzier@...> wrote:

> See below. Let me know if you need additional info.

Please compile milter-greylist and libspf2 with debug enabled.

Regards,
Nerijus

On Fri, 14 Mar 2008 22:16:49 +0100 "Johann E. Klasek" <johann@...> wrote:

> If this is not related to a the 64bit issue, I suggest to check the
> res_ninit-patch anyway.

Did you send these patches upstream?

Regards,
Nerijus

On Sat, Mar 15, 2008 at 12:35:46AM +0200, Nerijus Baliunas wrote:
> On Fri, 14 Mar 2008 22:16:49 +0100 "Johann E. Klasek" <johann@...> wrote:
> 
> > If this is not related to a the 64bit issue, I suggest to check the
> > res_ninit-patch anyway.
> 
> Did you send these patches upstream?

Sorry, not yet reported to the spf2 developers.
(just wondering about nothing happened since 1.2.5 so no one
else seems to report bugs or improvements?)
Will do it next (lost this on my todo list ;) ).

Johann K.

--- In milter-greylist@yahoogroups.com, "Johann E. Klasek" 
<johann@...> wrote:
>
> > > If this is not related to a the 64bit issue, I suggest to check 
the
> > > res_ninit-patch anyway.
> > 
> > Did you send these patches upstream?
> 
> Sorry, not yet reported to the spf2 developers.
> (just wondering about nothing happened since 1.2.5 so no one
> else seems to report bugs or improvements?)
> Will do it next (lost this on my todo list ;) ).

There are a number of known patches for libspf2-1.25

-rw-r--r--   1 root root  440 Feb 12  2007 libspf2-1.2.5-64bit.patch
-rw-r--r--   1 root root  337 Feb 12  2007 libspf2-1.2.5-bogus-
header.patch
-rw-r--r--   1 root root  40K Sep  5  2007 libspf2_1.2.5.dfsg-4.diff
-rw-r--r--   1 root root 8.5K Oct 22 10:30 libspf2-1.2.5-malloc.patch
-rw-r--r--   1 root root  900 Oct 19 18:35 libspf2-1.2.5-
res_ninit.patch

I had to collect them from various locations.  The spf2 developers 
are not interested in releasing a new version, just patches.

Here are a couple of pertinent ones:

*** libspf2-1.2.5/src/libspf2/spf_dns_resolv.c  Sat Feb 19 03:38:12 
2005
--- libspf2-1.2.5/src/libspf2/spf_dns_resolv.c  Wed Jun 20 15:15:26 
2007
***************
*** 144,151 ****
--- 144,163 ----
        if (res_spec == NULL) {
                res_state = (struct __res_state *)
                                                malloc(sizeof(struct 
__res_state));
+               if (res_state == NULL) {
+                       SPF_error("Failed to aquire res_state 
memory");
+                       return NULL;
+               }
+               /* Always initialize to zero, some resolver libary may
+                * try to expect an old state which will then used
+                * to cleanup from this previous state - if this is 
garbage
+                * the resolver library could raise a fault after 
some time ...
+                */
+               memset((void *)res_state, 0, sizeof(struct 
__res_state));
+
                if (res_ninit(res_state) != 0) {
                        SPF_error("Failed to call res_ninit()");
+                       return NULL;
                }
                pthread_setspecific(res_state_key, (void *)res_state);
        }


--- libspf2-1.2.5/src/libspf2/spf_interpret.c   2005-02-22 
03:41:27.000000000 +0000
+++ libspf2-1.2.5/src/libspf2/spf_interpret.c   2007-02-12 
08:02:20.000000000 +0000
@@ -48,9 +48,9 @@
        SPF_request_t   *spf_request;
        SPF_record_t    *spf_record;
        SPF_errcode_t    err;
-       char                    *buf;
-       int                              buflen;
-       int                              len;
+       char            *buf;
+       size_t           buflen;
+       size_t           len;

        SPF_ASSERT_NOTNULL(spf_response);
        spf_request = spf_response->spf_request;


Jim

The problem has gone away after applying the res_ninit patch.

Thanks for helping out!

--- In milter-greylist@yahoogroups.com, "Johann E. Klasek"
<johann@...> wrote:
>
> On Fri, Mar 14, 2008 at 09:39:32PM -0000, reschauzier wrote:
> > See below. Let me know if you need additional info.
> > 
> > Rudy.
> > 
> > Core was generated by `/usr/bin/milter-greylist -P
> > /var/milter-greylist/milter-greylist.pid -p /var/mi'.
> > Program terminated with signal 11, Segmentation fault.
> > #0  0x00c75f6c in free () from /lib/libc.so.6
> > (gdb)     thread apply all bt full
> > 
> [..]
> > 
> > Thread 1 (process 13734):
> > #0  0x00c75f6c in free () from /lib/libc.so.6
> > No symbol table info available.
> > #1  0x0014ae74 in __res_ndestroy () from /usr/lib/libbind.so.4
> > No symbol table info available.
> > #2  0x0014b7ee in __res_vinit () from /usr/lib/libbind.so.4
> > No symbol table info available.
> > #3  0x0014c4f5 in __res_ninit () from /usr/lib/libbind.so.4
> > No symbol table info available.
> > #4  0x00a71f9c in SPF_dns_resolv_new () from /usr/lib/libspf2.so.2
> > No symbol table info available.
> > #5  0x00a7003f in SPF_dns_lookup () from /usr/lib/libspf2.so.2
> > No symbol table info available.
> > #6  0x00a709b2 in SPF_dns_get_client_dom () from /usr/lib/libspf2.so.2
> > ---Type <return> to continue, or q <return> to quit---
> > No symbol table info available.
> > #7  0x00a7003f in SPF_dns_lookup () from /usr/lib/libspf2.so.2
> > No symbol table info available.
> > #8  0x00a7916f in SPF_server_get_record () from /usr/lib/libspf2.so.2
> > No symbol table info available.
> > #9  0x00a785c3 in SPF_request_query_mailfrom () from
/usr/lib/libspf2.so.2

> > No symbol table info available.
> [..]
> 
> This seems really to be the known res_ninit() issue (see my previous
> posting): The caller have to provide a private data segment, for
> subsequent resolver calls. If this memory area will be not cleared, some
> resolver-library versions are assuming non-zero values of the data
> structure as pointer to not returned malloc'd memory from the past - but
> this assumption is wrong if the malloc'd memory was not wiped with zeros
> and garbage is in the memory segment. Trying to apply free on such a
> surious pointer leads to a segmentation fault (sooner or later).
> 
> Hope this helps.
> 
> Johann K.
>

I have uploaded the finalized rpms and source rpms of milter-greylist
compiled with libspf2 support and the rpms for libspf2 itself to the
following location:

http://files.eschauzier.org/milter-greylist/

This directory also holds rpms for spamass-milter with an additional
patch to avoid scanning of messages from authenticated users (see
http://savannah.nongnu.org/patch/?5241)

Rudy.


--- In milter-greylist@yahoogroups.com, "reschauzier"
<reschauzier@...> wrote:
>
> The problem has gone away after applying the res_ninit patch.
> 
> Thanks for helping out!
> 
> --- In milter-greylist@yahoogroups.com, "Johann E. Klasek"
> <johann@> wrote:
> >
> > On Fri, Mar 14, 2008 at 09:39:32PM -0000, reschauzier wrote:
> > > See below. Let me know if you need additional info.
> > > 
> > > Rudy.
> > > 
> > > Core was generated by `/usr/bin/milter-greylist -P
> > > /var/milter-greylist/milter-greylist.pid -p /var/mi'.
> > > Program terminated with signal 11, Segmentation fault.
> > > #0  0x00c75f6c in free () from /lib/libc.so.6
> > > (gdb)     thread apply all bt full
> > > 
> > [..]
> > > 
> > > Thread 1 (process 13734):
> > > #0  0x00c75f6c in free () from /lib/libc.so.6
> > > No symbol table info available.
> > > #1  0x0014ae74 in __res_ndestroy () from /usr/lib/libbind.so.4
> > > No symbol table info available.
> > > #2  0x0014b7ee in __res_vinit () from /usr/lib/libbind.so.4
> > > No symbol table info available.
> > > #3  0x0014c4f5 in __res_ninit () from /usr/lib/libbind.so.4
> > > No symbol table info available.
> > > #4  0x00a71f9c in SPF_dns_resolv_new () from /usr/lib/libspf2.so.2
> > > No symbol table info available.
> > > #5  0x00a7003f in SPF_dns_lookup () from /usr/lib/libspf2.so.2
> > > No symbol table info available.
> > > #6  0x00a709b2 in SPF_dns_get_client_dom () from
/usr/lib/libspf2.so.2
> > > ---Type <return> to continue, or q <return> to quit---
> > > No symbol table info available.
> > > #7  0x00a7003f in SPF_dns_lookup () from /usr/lib/libspf2.so.2
> > > No symbol table info available.
> > > #8  0x00a7916f in SPF_server_get_record () from
/usr/lib/libspf2.so.2
> > > No symbol table info available.
> > > #9  0x00a785c3 in SPF_request_query_mailfrom () from
> /usr/lib/libspf2.so.2
> > > No symbol table info available.
> > [..]
> > 
> > This seems really to be the known res_ninit() issue (see my previous
> > posting): The caller have to provide a private data segment, for
> > subsequent resolver calls. If this memory area will be not
cleared, some
> > resolver-library versions are assuming non-zero values of the data
> > structure as pointer to not returned malloc'd memory from the past
- but
> > this assumption is wrong if the malloc'd memory was not wiped with
zeros

> > and garbage is in the memory segment. Trying to apply free on such a
> > surious pointer leads to a segmentation fault (sooner or later).
> > 
> > Hope this helps.
> > 
> > Johann K.
> >
>

Could you add this to the Wiki as well?
Would be a pity if it gets lost...
Thanks,

Ondrej

reschauzier wrote:

>
> I have uploaded the finalized rpms and source rpms of milter-greylist
> compiled with libspf2 support and the rpms for libspf2 itself to the
> following location:
>
> http://files.eschauzier.org/milter-greylist/
> <http://files.eschauzier.org/milter-greylist/>
>
> This directory also holds rpms for spamass-milter with an additional
> patch to avoid scanning of messages from authenticated users (see
> http://savannah.nongnu.org/patch/?5241
> <http://savannah.nongnu.org/patch/?5241>)
>
> Rudy.
>
> --- In milter-greylist@yahoogroups.com
> <mailto:milter-greylist%40yahoogroups.com>, "reschauzier"
> <reschauzier@...> wrote:
> >
> > The problem has gone away after applying the res_ninit patch.
> >
> > Thanks for helping out!
> >
> > --- In milter-greylist@yahoogroups.com
> <mailto:milter-greylist%40yahoogroups.com>, "Johann E. Klasek"
> > <johann@> wrote:
> > >
> > > On Fri, Mar 14, 2008 at 09:39:32PM -0000, reschauzier wrote:
> > > > See below. Let me know if you need additional info.
> > > >
> > > > Rudy.
> > > >
> > > > Core was generated by `/usr/bin/milter-greylist -P
> > > > /var/milter-greylist/milter-greylist.pid -p /var/mi'.
> > > > Program terminated with signal 11, Segmentation fault.
> > > > #0 0x00c75f6c in free () from /lib/libc.so.6
> > > > (gdb) thread apply all bt full
> > > >
> > > [..]
> > > >
> > > > Thread 1 (process 13734):
> > > > #0 0x00c75f6c in free () from /lib/libc.so.6
> > > > No symbol table info available.
> > > > #1 0x0014ae74 in __res_ndestroy () from /usr/lib/libbind.so.4
> > > > No symbol table info available.
> > > > #2 0x0014b7ee in __res_vinit () from /usr/lib/libbind.so.4
> > > > No symbol table info available.
> > > > #3 0x0014c4f5 in __res_ninit () from /usr/lib/libbind.so.4
> > > > No symbol table info available.
> > > > #4 0x00a71f9c in SPF_dns_resolv_new () from /usr/lib/libspf2.so.2
> > > > No symbol table info available.
> > > > #5 0x00a7003f in SPF_dns_lookup () from /usr/lib/libspf2.so.2
> > > > No symbol table info available.
> > > > #6 0x00a709b2 in SPF_dns_get_client_dom () from
> /usr/lib/libspf2.so.2
> > > > ---Type <return> to continue, or q <return> to quit---
> > > > No symbol table info available.
> > > > #7 0x00a7003f in SPF_dns_lookup () from /usr/lib/libspf2.so.2
> > > > No symbol table info available.
> > > > #8 0x00a7916f in SPF_server_get_record () from
> /usr/lib/libspf2.so.2
> > > > No symbol table info available.
> > > > #9 0x00a785c3 in SPF_request_query_mailfrom () from
> > /usr/lib/libspf2.so.2
> > > > No symbol table info available.
> > > [..]
> > >
> > > This seems really to be the known res_ninit() issue (see my previous
> > > posting): The caller have to provide a private data segment, for
> > > subsequent resolver calls. If this memory area will be not
> cleared, some
> > > resolver-library versions are assuming non-zero values of the data
> > > structure as pointer to not returned malloc'd memory from the past
> - but
> > > this assumption is wrong if the malloc'd memory was not wiped with
> zeros
> > > and garbage is in the memory segment. Trying to apply free on such a
> > > surious pointer leads to a segmentation fault (sooner or later).
> > >
> > > Hope this helps.
> > >
> > > Johann K.
> > >
> >
>
>

Maybe the 'Binaries' page should be renamed to 'Downloads', that way  
all the download links are in one place.

I tried this, but I get the message, only site administrators are  
allowed to do this.

Bill

On Mar 19, 2008, at 8:50 AM, Ondrej Valousek wrote:

> Could you add this to the Wiki as well?
> Would be a pity if it gets lost...
> Thanks,
>
> Ondrej
>
> reschauzier wrote:
>>
>> I have uploaded the finalized rpms and source rpms of milter-greylist
>> compiled with libspf2 support and the rpms for libspf2 itself to the
>> following location:
>>
>> http://files.eschauzier.org/milter-greylist/
>> <http://files.eschauzier.org/milter-greylist/>
>>
>> This directory also holds rpms for spamass-milter with an additional
>> patch to avoid scanning of messages from authenticated users (see
>> http://savannah.nongnu.org/patch/?5241
>> <http://savannah.nongnu.org/patch/?5241>)
>>
>> Rudy.
>>
>> --- In milter-greylist@yahoogroups.com
>> <mailto:milter-greylist%40yahoogroups.com>, "reschauzier"
>> <reschauzier@...> wrote:
>>>
>>> The problem has gone away after applying the res_ninit patch.
>>>
>>> Thanks for helping out!
>>>
>>> --- In milter-greylist@yahoogroups.com
>> <mailto:milter-greylist%40yahoogroups.com>, "Johann E. Klasek"
>>> <johann@> wrote:
>>>>
>>>> On Fri, Mar 14, 2008 at 09:39:32PM -0000, reschauzier wrote:
>>>>> See below. Let me know if you need additional info.
>>>>>
>>>>> Rudy.
>>>>>
>>>>> Core was generated by `/usr/bin/milter-greylist -P
>>>>> /var/milter-greylist/milter-greylist.pid -p /var/mi'.
>>>>> Program terminated with signal 11, Segmentation fault.
>>>>> #0 0x00c75f6c in free () from /lib/libc.so.6
>>>>> (gdb) thread apply all bt full
>>>>>
>>>> [..]
>>>>>
>>>>> Thread 1 (process 13734):
>>>>> #0 0x00c75f6c in free () from /lib/libc.so.6
>>>>> No symbol table info available.
>>>>> #1 0x0014ae74 in __res_ndestroy () from /usr/lib/libbind.so.4
>>>>> No symbol table info available.
>>>>> #2 0x0014b7ee in __res_vinit () from /usr/lib/libbind.so.4
>>>>> No symbol table info available.
>>>>> #3 0x0014c4f5 in __res_ninit () from /usr/lib/libbind.so.4
>>>>> No symbol table info available.
>>>>> #4 0x00a71f9c in SPF_dns_resolv_new () from /usr/lib/libspf2.so.2
>>>>> No symbol table info available.
>>>>> #5 0x00a7003f in SPF_dns_lookup () from /usr/lib/libspf2.so.2
>>>>> No symbol table info available.
>>>>> #6 0x00a709b2 in SPF_dns_get_client_dom () from
>> /usr/lib/libspf2.so.2
>>>>> ---Type <return> to continue, or q <return> to quit---
>>>>> No symbol table info available.
>>>>> #7 0x00a7003f in SPF_dns_lookup () from /usr/lib/libspf2.so.2
>>>>> No symbol table info available.
>>>>> #8 0x00a7916f in SPF_server_get_record () from
>> /usr/lib/libspf2.so.2
>>>>> No symbol table info available.
>>>>> #9 0x00a785c3 in SPF_request_query_mailfrom () from
>>> /usr/lib/libspf2.so.2
>>>>> No symbol table info available.
>>>> [..]
>>>>
>>>> This seems really to be the known res_ninit() issue (see my  
>>>> previous
>>>> posting): The caller have to provide a private data segment, for
>>>> subsequent resolver calls. If this memory area will be not
>> cleared, some
>>>> resolver-library versions are assuming non-zero values of the data
>>>> structure as pointer to not returned malloc'd memory from the past
>> - but
>>>> this assumption is wrong if the malloc'd memory was not wiped with
>> zeros
>>>> and garbage is in the memory segment. Trying to apply free on  
>>>> such a
>>>> surious pointer leads to a segmentation fault (sooner or later).
>>>>
>>>> Hope this helps.
>>>>
>>>> Johann K.
>>>>
>>>
>>
>>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>

On Wed, Mar 19, 2008 at 5:14 PM, Bill Levering <idbill@...> wrote:
> Maybe the 'Binaries' page should be renamed to 'Downloads', that way
>  all the download links are in one place.

I've fixed this now, I think we will have to restructure the wiki a
few times in the beginning as new content pours in. I've added some
material myself and it didn't fit with the choices I initially made.

>  I tried this, but I get the message, only site administrators are
>  allowed to do this.

I guess that's part of the default permission set, I've opened them up
a little earlier already and will look at it again as soon as we reach
some stability in content and structure. I see there's also moderators
that can be assigned, maybe you would be interested in something like
that?

Thank you for your contributions!

For those who have missed that we now have a wiki, here's the link:
http://milter-greylist.wikidot.com

-- 
/peter