Yahoo Groups archive

Milter-greylist

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

Message

Re: [milter-greylist] Re: termination after rcpt flood

2008-03-21 by Ondrej Valousek

Hi Johann,

Thanks for the advice.
Actually - I have already found the cause of the last problem - the main
database in memory got corrupted during the milter run which caused that
some pointer holding the sender's email address (i.e. one part of the
triplet) was overwritten.
Later on, when the triplet was about to be expired, milter-greylist
released the resources and bailed out when freeing the invalid memory
where the pointer pointed.
This is kind of programmer's nightmare, I would say - even core dump
would not help you here.

The only thing I am wondering about is whether maybe the spf dynamic
library might have caused this. Is it possible for a dynamic library to
overwrite memory that the calling process is using?
I am asking because I am using the unpatched version of the libspf2 -
and I read about the problems it caused to other guys...

Thanks,
Ondrej

Johann E. Klasek wrote:
>
> On Wed, Mar 19, 2008 at 10:22:22AM +0100, Ondrej Valousek wrote:
> > Hi Johann,
> >
> > Ok I see the point.
> > I was trying to figure out how much memory is the milter-greylist using
> > on my system using the top command and I am not sure whether it gives me
> > the accurate results.
> > Do I have the feed top command with some additional switches to find out
> > the total amount of resources it consumes?
>
> Just look at the "VIRT" column.
> You can also use the command "pmap PID" available under Linux or Solaris.
> The latter serves a more detailed view of allocated chunks in virutal
> memory.
>
> >
> > I am just trying to find out why it has died last time - was it just a
> > lack of system resources, not enough file descriptors or broken spf
> > library (saw the last discussion).
> > At the moment I have nothing to start with.
> > Maybe I could enable the verbose logging or enable core files (not sure
> > what is the best).
>
> Just enable core dumping.
>
> Note to Fedora users: write into the appropriate sysconfig file
>
> DAEMON_COREFILE_LIMIT=unlimited
>
> to enable core dump creation.
>
> Use gdb to see the backtrace ...
>
> gdb -d milter-greylist-source-dir Binary Corefile
> (gdb) backtrace
>
> I hope you catch the beast ;)
>
> Johann
>
>

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.