[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Milter (spamassassin): to error state : spamassassin milter seems to

From: Dan Nelson
Subject: Re: Milter (spamassassin): to error state : spamassassin milter seems to randomly fail
Date: Fri, 15 Aug 2003 10:56:39 -0500
User-agent: Mutt/1.5.4i

In the last episode (Aug 15), Joost van Baal said:
> I am running spamass-milter 0.2, using the 0.2.0-1 Debian package,
> from Don Armstrong, backported to Debian GNU/Linux woody.  About once
> a day, the filter stops functioning:
>  Aug 14 12:30:07 babbage sm-mta[10175]: h7EAQ7QE010175: Milter 
> (spamassassin): timeout before data read
>  Aug 14 12:30:07 babbage sm-mta[10175]: h7EAQ7QE010175: Milter 
> (spamassassin): to error state
> What do other people do to work around this?  Just restart every so
> many minutes, no matter what?  (Do I really have to do such an ugly
> thing?)
> Would it be useful if I give you more info on the precise
> circumstances? If so, please be quick to ask: I am able to do some
> testing on the machine now, but will no longer be able to within
> about a week.  I have no experience whatsoever with the valgrind
> memory debugger, but am willing to invest some time in this or
> similar tools.

I have finally been able to reproduce this on my system and am trying
to debug it.  gdb gives incomplete information on inline class methods,
so I'm trying a build with -O0 -fno-default-inline.  If I still can't
debug it I'll start converting the function in question to C, which is
at least debuggable.

Actually, if you can build with the same flags on your RedHat or
Solaris box and get me a stack trace, that might help.  My problem is
that all my stacks look like this:

#0  0x0804b8ca in mlfi_envrcpt(smfi_str*, char**) (ctx=0x8067380,
    envrcpt=0x805b080) at /usr/include/c++/3.3/bits/basic_string.h:249
#1  0x2808b116 in mi_clr_macros () from /usr/lib/
#2  0x2808a642 in mi_engine () from /usr/lib/

gdb collapsed the inline string operation on top of the code in
mlfi_envrcpt, so I have no idea where in the function it died.

        Dan Nelson

reply via email to

[Prev in Thread] Current Thread [Next in Thread]