From: "Justin Mason" <[EMAIL PROTECTED]>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
> John Narron writes:
> > > -----Original Message-----
> > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> > > -----BEGIN PGP SIGNED MESSAGE-----
> > > Hash: SHA1
> > >
> > >
> > > ah, so it does.
> > > http://article.gmane.org/gmane.mail.spam.spamassassin.general/70459
> > >
> > > so it couldn't be fixed with a simple 'ulimit -s unlimited'?
> > >
> >
> > Nope. At least not on FreeBSD 5.4. Far from being an expert on
FreeBSD,
> > but the stack size's hardlimit seems to be set in the kernel (the
MAXSSIZ
> > option). By default its 65536 (64MB). Increasing the MAXSSIZ, after
> > Recompiling and rebooting the new kernel to 131072 (128MB) helped, but
> > not enough to overcome this (in other words, it would get further
through
> > the $evalstr statement, but not completely).
> >
> > Again, I'm not really pointing my finger at spamassassin, just really
> > relaying the information out so people who have yet to encounter this
> > problem can find a way to fix it. Its something in perl 5.8.7, but I
don't
> > know specifically what it is. Another possible fix is for spamassassin
to
> > not 'eval' such a lengthy string.
>
> unfortunately, I'm not sure if there's a workable workaround for that.
>
> if you can come up with a pure-perl, non-spamassassin-based test case, it
> might be worth reporting it to the perl maintainers via "perlbug"...
> sounds like they've made some stack-size assumptions that are not
> valid on FreeBSD by default.
>
> - --j.
I am wondering if this somehow gets translated to the insecure dependency
errors on Linux with the evalstr operation. It sounds suspicious.
{^_^}
