You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@spamassassin.apache.org by Justin Mason <jm...@jmason.org> on 2004/03/08 20:02:31 UTC

Re: mass-check failed

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


Theo Van Dinter writes:
> On Mon, Mar 08, 2004 at 10:48:50AM -0600, Michael Parker wrote:
> > Deep recursion on subroutine
> > "Mail::SpamAssassin::Message::Node::content_summary" at
> > /home/parker/SA/spamassassin-corpora/masses/../lib/Mail/SpamAssassin/Message/Node.pm
> > line 423.
> > Out of memory!
> 
> Hrm.  The only rule which uses that is the MPART_ALT_DIFF code.  I guess
> it depends what is meant by "deep recursion" -- ie: how many times
> it that?  ;)

Let's add a depth restriction, anyway, since there's no way we should
parse a MIME message 100 levels deep (for example) -- it'll just
result in resource exhaustion and I doubt many MUAs support it.

> > some ideas.  Also, given that I know the msgid of the last message
> > written to the logs, how do I find which message would be next up for
> > processing?
> 
> Heh.  It's unfortunately not that easy.  You'd need the list of messages,
> which doesn't get output in any useful way...  You can edit the code in
> ArchiveIterator to not unlink the temp file.  Then that would tell you
> the messages in order.

Probably something we should add to mass-check as a switch, because I
can see that being useful info quite frequently.

- --j.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Exmh CVS

iD8DBQFATMNHQTcbUG5Y7woRAtVsAKDLUvF8YhUm9ArRnlqT6bEciynuqgCeJwGK
KXxRN8Tl1q2tJps0dMa4P4M=
=X/uj
-----END PGP SIGNATURE-----


Re: mass-check failed

Posted by Theo Van Dinter <fe...@kluge.net>.
On Mon, Mar 08, 2004 at 11:02:31AM -0800, Justin Mason wrote:
> Let's add a depth restriction, anyway, since there's no way we should
> parse a MIME message 100 levels deep (for example) -- it'll just
> result in resource exhaustion and I doubt many MUAs support it.

Arguably though, if content_summary gets stuck, find_parts or the parser
itself should get stuck.

> Probably something we should add to mass-check as a switch, because I
> can see that being useful info quite frequently.

Yeah.  This would be part of the resume capability as well... :)

-- 
Randomly Generated Tagline:
ep.