You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@spamassassin.apache.org by Michael Scheidell <sc...@secnap.net> on 2010/02/14 15:45:08 UTC
SA 330 compile error. where do I start looking
only does this on ONE system. all have similar setups, same ram, same
cpu, same rev or re2c, same os.
so out of hundreds of systems, why does this one die? why with sa 330
and not sa 325?
(yes, its a sares rule, yes, we don't need them anymore), but sa-compile
is seeing something that is creating code that is segfaulting when
compiling.
and in fact, it either segv's in the compiler, and os catches it, or,
every now and then, crashes the os and causes it to reboot.
if I leave in SARE_EN_A_4XX_1 compiler segv's. if I comment it out,
computer crashes. if I comment them BOTH out, it compiles.
re2c 0.13.5
sa 3.30
os: freebsd 6.4, i386
perl: 5.8.8
ram : 1gb
cpu: CPU: Intel(R) Core(TM)2 CPU 4300 @ 1.80G with
hyperthreading enabled.
scanner2.c: In function `Mail_SpamAssassin_CompiledRegexps_body_0_scan2':
scanner2.c:14465: internal compiler error: Segmentation fault: 11
wc -l scanner2.c
14465 scanner2.c
last few lines are:
yy6889:
yych = *++YYCURSOR;
if (yych != 'i') goto yy6;
yych = *++YYCURSOR;
if (yych != 'n') goto yy6;
yych = *++YYCURSOR;
if (yych != 'a') goto yy6;
yych = *++YYCURSOR;
if (yych != 'l') goto yy6;
yych = *++YYCURSOR;
if (yych != ' ') goto yy6;
yych = *++YYCURSOR;
if (yych != 'a') goto yy6;
yych = *++YYCURSOR;
if (yych != 'v') goto yy6;
yych = *++YYCURSOR;
if (yych != 'e') goto yy6;
++YYCURSOR;
{RET("FR_CALL_PRICE SARE_EN_A_4XX_1");}
}
}
egrep 'FR_CALL_PRICE SARE_EN_A_4XX_1' *
SARE_EN_A_4XX_1 /4(?:-1150 N. Terminal Ave. Nanaim[o0], British|0
Exchange Place Suite 420 New York|001 Kennett Pike, Suite 134,
Greenville, DE|011 1\/2 Riverside Dr Burbank, CA| ?0 ?4 E\. 1st \# ?1 ?3
?4 ?5 Long Beach, CA|2 Lake Ave \#211 Danbury,CT|30 Technology Parkway
Norcross, GA|33 Plaza Real Suite 275, Boca Raton, FL|405 NW 73 Av\.
MIAMI, FL 33166|50 7th Avenue Suite 1605|50 NE 20th Street, Suite
113|509 S\. 143rd Street, Suite 9 - Omaha|60 Park Ave South 9th Floor,
New York, NY|600 Madison Avenue, Suite 500 Kansas City|611 Hardscrabble
Road, Suite 109, Columbia, SC|770 N\.W\. Boca Raton Blvd\. Suite B|800
BASELINE RD, STE E104 \#280|833 Saratoga \#140 Corpus Christi, Tx|92-C
Cedar Lane, \#302, Teaneck, NJ)/i
body FR_CALL_PRICE /[0-9] ?(?:.|Eur(?:os|\.)?) ?(?:\/|par)
?(?:min(?:\.|ute)?|appel)\b/i
--
Michael Scheidell, CTO
Phone: 561-999-5000, x 1259
> *| *SECNAP Network Security Corporation
* Certified SNORT Integrator
* 2008-9 Hot Company Award Winner, World Executive Alliance
* Five-Star Partner Program 2009, VARBusiness
* Best Anti-Spam Product 2008, Network Products Guide
* King of Spam Filters, SC Magazine 2008
______________________________________________________________________
This email has been scanned and certified safe by SpammerTrap(r).
For Information please see http://www.secnap.com/products/spammertrap/
______________________________________________________________________
Re: SA 330 compile error. where do I start looking
Posted by jdow <jd...@earthlink.net>.
From: "Michael Scheidell" <sc...@secnap.net>
Sent: Sunday, 2010/February/14 15:27
> On 2/14/10 9:50 AM, Karsten Bräckelmann wrote:
>> Bad RAM?
>>
>>
> well, it didn't start till SA 3.30, and deleting those two rules stopped
> the seg fault and crash..
>
> more likely a bad ST 504 controller.
Somebody is running SpamAssassin on an original IBM PC with a hard
disk?
{^_-} I'll go back to my room... Wait, I'm there. You guys are out
of luck.
Re: SA 330 compile error. where do I start looking
Posted by Karsten Bräckelmann <gu...@rudersport.de>.
On Sun, 2010-02-14 at 18:27 -0500, Michael Scheidell wrote:
> On 2/14/10 9:50 AM, Karsten Bräckelmann wrote:
> > Bad RAM?
>
> well, it didn't start till SA 3.30, and deleting those two rules stopped
> the seg fault and crash..
Well, I've seen bad RAM do strange things like that before. In the
middle of a full desktop build, the build randomly crapped out. Resuming
the build helped, and I eventually got to the end. Yes, the entire time
I was working on that machine with no issue...
It was the description and the identical setup of a bunch of machines,
with *one* only showing the issue that triggered my suspicion.
> more likely a bad ST 504 controller.
Maybe. *shrug* I'd check the RAM nonetheless. You know, it usually just
takes a few seconds for memtest to light up like a Christmas tree if the
RAM is faulty.
--
char *t="\10pse\0r\0dtu\0.@ghno\x4e\xc8\x79\xf4\xab\x51\x8a\x10\xf4\xf4\xc4";
main(){ char h,m=h=*t++,*x=t+2*h,c,i,l=*x,s=0; for (i=0;i<l;i++){ i%8? c<<=1:
(c=*++x); c&128 && (s+=h); if (!(h>>=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}
Re: SA 330 compile error. where do I start looking
Posted by Michael Scheidell <sc...@secnap.net>.
On 2/14/10 9:50 AM, Karsten Bräckelmann wrote:
> Bad RAM?
>
>
well, it didn't start till SA 3.30, and deleting those two rules stopped
the seg fault and crash..
more likely a bad ST 504 controller.
--
Michael Scheidell, CTO
Phone: 561-999-5000, x 1259
> *| *SECNAP Network Security Corporation
* Certified SNORT Integrator
* 2008-9 Hot Company Award Winner, World Executive Alliance
* Five-Star Partner Program 2009, VARBusiness
* Best Anti-Spam Product 2008, Network Products Guide
* King of Spam Filters, SC Magazine 2008
______________________________________________________________________
This email has been scanned and certified safe by SpammerTrap(r).
For Information please see http://www.secnap.com/products/spammertrap/
______________________________________________________________________
Re: SA 330 compile error. where do I start looking
Posted by Karsten Bräckelmann <gu...@rudersport.de>.
On Sun, 2010-02-14 at 09:45 -0500, Michael Scheidell wrote:
> only does this on ONE system. all have similar setups, same ram, same
> cpu, same rev or re2c, same os.
> so out of hundreds of systems, why does this one die? why with sa 330
> and not sa 325?
> (yes, its a sares rule, yes, we don't need them anymore), but sa-compile
> is seeing something that is creating code that is segfaulting when
> compiling.
> and in fact, it either segv's in the compiler, and os catches it, or,
> every now and then, crashes the os and causes it to reboot.
Bad RAM?
--
char *t="\10pse\0r\0dtu\0.@ghno\x4e\xc8\x79\xf4\xab\x51\x8a\x10\xf4\xf4\xc4";
main(){ char h,m=h=*t++,*x=t+2*h,c,i,l=*x,s=0; for (i=0;i<l;i++){ i%8? c<<=1:
(c=*++x); c&128 && (s+=h); if (!(h>>=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}