Carview!

CARVIEW

MOTORHOMES

Select Language

HTTP/2 200 cache-control: max-age=43200 server: Combust/Plack (Perl) vary: Accept-Encoding content-encoding: gzip content-length: 2379 content-type: text/html; charset=utf-8 last-modified: Tue, 14 Oct 2025 05:50:24 GMT date: Tue, 14 Oct 2025 05:50:24 GMT strict-transport-security: max-age=15768000 Re: Fighting the Good Fight against spam deluge (was: Senatorial (Senescent?) reflective pause) - nntp.perl.org

Front page | perl.perl5.porters | Postings from August 2008

Re: Fighting the Good Fight against spam deluge (was: Senatorial (Senescent?) reflective pause)

Thread Previous | Thread Next

From:

Date:

August 1, 2008 03:04

Subject:

Re: Fighting the Good Fight against spam deluge (was: Senatorial (Senescent?) reflective pause)

Message ID:

20080801100359.32DEE30C0B1@jmason.org

Tim Bunce writes:
> On Thu, Jul 31, 2008 at 04:15:49PM -0600, Tom Christiansen wrote:
> > 
> > I do have another Perl-spin bug/problem related, but I am pretty sure 
> > this is some pessimal combo of input data and processing code.  Here's
> > an example of it:
> > 
> >       UID   PID  PPID CPU PRI NI   VSZ   RSS WCHAN   STAT TT       TIME COMMAND
> > 	0  2463  3795   0   2 20 44920 10020 poll   I     ??   14:42.02 perl5.10.0: spamd child (perl5.10.0)
> > 
> > Nearly 15 minutes CPU time to process one message?!
Note that spamd reuses forked children, so that process has probably
processed more than 1 msg.
> > That's SpamAssassin's spamd(1) servicing a spamc(1) client.  I figure
> > that somewhere there must be a regex in SpamAssassin that could use
> > nonbacktracking, whether (?>...) or possessive quantifiers or perhaps
> > the new "backtracking control verbs".  
> > 
> > But I don't know where it is, and haven't the patience to track 
> > it down.  So I just kill those off when they take too long.
> 
> My usual first approach is something like
> 
>  $SIG{USR2} = \&Carp::cluck; # or \&Carp::confess;
spamd handily already does that. ;)  Send it a SIGUSR2 and it'll
dump a backtrace, and the current message's Message-ID.
If you can capture a message that causes one of the standard rules to go
exponential, please open a bug at https://issues.apache.org/SpamAssassin/
and we'll track down the regexp and fix it.  (If it's a perl bug, we'll
then open it in _that_ bug tracker ;)
--j.

Thread Previous | Thread Next