Yahoo Groups archive

Milter-greylist

Index last updated: 2026-04-28 23:32 UTC

Message

Re: [milter-greylist] Re: Milter Greylist crashes with libspf2

2008-03-19 by Ondrej Valousek

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.
> > >
> >
>
>

Attachments

Move to quarantaine

This moves the raw source file on disk only. The archive index is not changed automatically, so you still need to run a manual refresh afterward.