-----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'? - --j. John Narron writes: > We've already determined that it is a stack-size problem, see the original > e-mail > > John Narron | "Sacrifice, they always say > Network Administration | Is a sign of nobility > CDS/CDSinet, LLC | But where does one draw the line > http://www.cdsinet.net | In the face of injury?" > (660) 886 4045 | - Queensryche > > > -----Original Message----- > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > > Sent: Tuesday, July 26, 2005 1:02 PM > > To: [EMAIL PROTECTED] > > Cc: users@spamassassin.apache.org > > Subject: Re: SpamAssassin, FreeBSD, Perl 5.8.7, bus errors, oh my! > > > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > > > > That sounds like a "ulimit" problem. Check your process limits... > > > > - --j. > > > > John Narron writes: > > > The line in $evalstr that causes the stack fault is: > > > > > > if ($self->{conf}->{scores}->{q{WLS_URI_OPT_377}}) { > > > > > > Which is on line 21720 (out of ~30800 lines). From what I've > > > gathered, each rule in the .cf files results in 4 lines > > being strung together in $evalstr: > > > > > > if ($self->{conf}->{scores}->{q{<RULE_NAME>}}) { > > > <RULE_NAME>_uri_test($self, @_); # call > > procedurally for speed > > > } > > > > > > It doesn't matter which rule is on line 21720 (as I've changed them > > > around to make sure it wasn't specifically WLS_URI_OPT_377, from > > > sa-blacklist.current.uri.cf), It seems when you get to > > line 21720 w/ > > > a 64MB stack on FreeBSD 5.4 w/ perl 5.8.7 etc, etc. that you've ran > > > out of stack space. This is part of the gdb bt from a > > perl5.8.7.core that I had: > > > > > > #0 0x280a2144 in Perl_malloc (nbytes%) at malloc.c:1411 > > > #1 0x281075b5 in S_save_hek_flags (str=0x935b328 > > "WLS_URI_OPT_377", > > > len, hash20016264, flags=0) at hv.c:97 > > > #2 0x2810aa51 in S_share_hek_flags (str=0x935b328 > > "WLS_URI_OPT_377", > > > len, hash20016264, flags=0) at hv.c:2114 > > > #3 0x2810a940 in Perl_share_hek (str=0x935b328 "WLS_URI_OPT_377", > > > len, > > > hash20016264) at hv.c:2074 > > > #4 0x28129e29 in Perl_newSVpvn_share (src=0x935b328 > > > "WLS_URI_OPT_377", len, hash20016264) at sv.c:6876 > > > #5 0x280def33 in Perl_peep (o=0x935f288) at op.c:6699 > > > #6 0x280debcc in Perl_peep (o=0x935ef88) at op.c:6634 ... (lots of > > > calls to Perl_peep, o= different numbers each time.. I'm > > assuming it's > > > a recursive function) > > > #5432 0x280debcc in Perl_peep (o=0x8081108) at op.c:6634 > > > #5433 0x280debcc in Perl_peep (o=0x8587a48) at op.c:6634 > > > #5434 0x280debcc in Perl_peep (o=0x8062b08) at op.c:6634 > > > #5435 0x280d10d5 in Perl_newPROG (o=0x8062b88) at op.c:1952 > > > #5436 0x280cac39 in Perl_yyparse () at perly.y:140 > > > #5437 0x28155eb7 in S_doeval (gimme8, startop=0x0, > > outside=0x805829c, > > > seq=0) at pp_ctl.c:2892 > > > #5438 0x281588ef in Perl_pp_entereval () at pp_ctl.c:3486 > > > #5439 0x280f8ebe in Perl_runops_debug () at dump.c:1452 #5440 > > > 0x2809be1f in S_run_body (oldscope=1) at perl.c:2000 > > > #5441 0x2809b8d5 in perl_run (my_perl=0x804e1f0) at perl.c:1919 > > > #5442 0x08049188 in main () > > > > > > (5434 (first Perl_peep line) - 4 (line after last Perl_peep) * 4 = > > > 21720 > > > > > > John Narron | "Sacrifice, they always say > > > Network Administration | Is a sign of nobility > > > CDS/CDSinet, LLC | But where does one draw the line > > > http://www.cdsinet.net | In the face of injury?" > > > (660) 886 4045 | - Queensryche > > > > > > > -----Original Message----- > > > > From: Loren Wilton [mailto:[EMAIL PROTECTED] > > > > Sent: Tuesday, July 26, 2005 12:06 PM > > > > To: users@spamassassin.apache.org > > > > Subject: Re: SpamAssassin, FreeBSD, Perl 5.8.7, bus errors, oh my! > > > > > > > > > I find out where in $evalstr that the Bus Error occurs. > > > > Removing the > > > > > offending line, and everything after results with a successful > > > > > eval call. > > > > > > > > Hum. It might be mildly interesting to know what the > > line is that > > > > causes the stack fault. I assume this is generated code, and > > > > possibly a slight change in what is being generated could > > reduce or > > > > eliminate the recursion that I assume is occuring. I'd > > think that > > > > code should be reasonably simple but... > > > > > > > > Loren > > > > > > > > > > > > > -----BEGIN PGP SIGNATURE----- > > Version: GnuPG v1.2.5 (GNU/Linux) > > Comment: Exmh CVS > > > > iD8DBQFC5nqlMJF5cimLx9ARAvblAKCDJiwyskuukYQ4fuVT0eEQiAEAwgCcD+Pd > > nd7wTSBmXKXw2ZWtzqNhPCE> =fp1d > > -----END PGP SIGNATURE----- > > > > > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) Comment: Exmh CVS iD8DBQFC5p7TMJF5cimLx9ARAmyiAJwO7XPq87g5MjIkxArH8KV7bZwQIQCdGfFX YmNWrwzsQlqwHGwP8G0DYUw= =hqxZ -----END PGP SIGNATURE-----
