Fyi, it looks like this may be (?) related to re2c. Previous, recent trunk
builds of SpamAssassin did /not/ have this problem.

Currently, in my conole log, i'm seeing:

	Fri Jun  8 22:26:46 2007 crashdump[1700]: Finished writing crash report to:
/Library/Logs/CrashReporter/re2c.crash.log

at sa-compile time.

Here's the crash log for that event:

**********

Host Name:      telemann
Date/Time:      2007-06-08 22:26:45.964 -0700
OS Version:     10.4.9 (Build 8P135)
Report Version: 4

Command: re2c
Path:    /usr/local/bin/re2c
Parent:  perl [437]

Version: ??? (???)

PID:    1699
Thread: 0

Exception:  EXC_BAD_ACCESS (0x0001)
Codes:      KERN_PROTECTION_FAILURE (0x0002) at 0x00000038

Thread 0 Crashed:
0   libSystem.B.dylib 	0x900288a0 fwrite + 96
1   re2c              	0x000224ec re2c::basic_filebuf_lc<char,
std::char_traits<char> >::~basic_filebuf_lc [in-charge deleting]() + 76
(basic_string.h:269)
2   re2c              	0x000217c0 re2c::basic_ofstream_lc<char,
std::char_traits<char> >::~basic_ofstream_lc [in-charge]() + 128 (stream_lc.h:315)
3   re2c              	0x00011c28 main + 3000 (main.cc:398)
4   re2c              	0x00001cac _start + 760
5   re2c              	0x000019b0 start + 48

Thread 0 crashed with PPC Thread State 64:
  srr0: 0x00000000900288a0 srr1: 0x000000000000f030                       
vrsave: 0x0000000000000000
    cr: 0x84000442          xer: 0x0000000000000005   lr: 0x0000000090028848 
ctr: 0x0000000090028840
    r0: 0x00000000bfffc6f8   r1: 0x00000000bfffc6c0   r2: 0x0000000000000001  
r3: 0x00000000a4c45d98
    r4: 0x0000000000000001   r5: 0x0000000000000000   r6: 0x0000000000000000  
r7: 0x0000000000000000
    r8: 0x00000000004007e2   r9: 0x000000000002a314  r10: 0x000000000002a2fc 
r11: 0x0000000000029ff0
   r12: 0x0000000090028840  r13: 0x0000000000000000  r14: 0x0000000000000000 
r15: 0x0000000000000000
   r16: 0x0000000000000000  r17: 0x00000000bfffc9fc  r18: 0x0000000000031080 
r19: 0x00000000bfffc850
   r20: 0x00000000bfffc964  r21: 0x00000000bfffc82c  r22: 0x0000000000031080 
r23: 0x00000000bfffca94
   r24: 0x00000000bfffcb30  r25: 0x0000000000031080  r26: 0x0000000000000001 
r27: 0x00000000a0001fac
   r28: 0x0000000000000000  r29: 0x0000000000000000  r30: 0x0000000000000000 
r31: 0x0000000090028848

Binary Images Description:
    0x1000 -    0x28fff re2c 	/usr/local/bin/re2c
0x8fe00000 - 0x8fe52fff dyld 46.12	/usr/lib/dyld
0x90000000 - 0x901bdfff libSystem.B.dylib 	/usr/lib/libSystem.B.dylib
0x90215000 - 0x9021afff libmathCommon.A.dylib 	/usr/lib/system/libmathCommon.A.dylib
0x91431000 - 0x9143cfff libgcc_s.1.dylib 	/usr/lib/libgcc_s.1.dylib
0x94c37000 - 0x94ca8fff libstdc++.6.dylib 	/usr/lib/libstdc++.6.dylib

are you using re2c version 0.12.x?  you need to, prior versions are buggy.

My current re2c version is from svn trunk (v 0.13.x),

svn info
  Path: .
  URL: https://re2c.svn.sourceforge.net/svnroot/re2c/trunk/re2c
  Repository Root: https://re2c.svn.sourceforge.net/svnroot/re2c
  Repository UUID: 642ea486-5414-0410-9d7f-a0204ed87703
  Revision: 760
  Node Kind: directory
  Schedule: normal
  Last Changed Author: helly
  Last Changed Rev: 758
  Last Changed Date: 2007-05-23 11:31:01 -0700 (Wed, 23 May 2007)

it could be a bug in the (as yet unreleased) development code.  could you try
with re2c 0.12.1?

Downgrading re2c to version 0.12.1 works OK.  re2c v0.13.x reproducibly does not.

I understand that v0.13.x is "(as yet unreleased) development code".  That's
also true of SA 3.3.x.

Might I ask, then: What /are/ the re2c version requirements, and where are they
stated?

On the mailing list, I believe I'd only found references to using "at least"
0.12.something-or-other.

In "Changes", there's "note re2c version requirements for sa-compile".  As far
as I can tell, it doesn't tell me WHERE it's noted.

Digging with "grep re2c `grep -rlni re2c .`"

	./.svn/text-base/Changes.svn-base:note re2c version requirements for sa-compile
	./.svn/text-base/sa-compile.raw.svn-base:          "Have you got a
sufficiently-recent version of re2c?\n".
	./blib/script/sa-compile:          "Have you got a sufficiently-recent version
of re2c?\n".
	./sa-compile:          "Have you got a sufficiently-recent version of re2c?\n".
	./sa-compile.raw:          "Have you got a sufficiently-recent version of re2c?\n".


And looking in "sa-compile" I can find only,

    # scannerN() functions
    if ($? >> 8 != 0) {
      my $cwd = `pwd`; chop $cwd;
      die "'$cmd' failed, dying!\n".
->        "Have you got a sufficiently-recent version of re2c?\n".
      "see $cwd/scanner$_.re\n";
    }

Or, is it obviously stated, and I have simply missed it?

As for v0.13.x of re2c, it seems from your comment that you believe it's a bug
in re2c, rather than anything in SA.  I'm not qualified to verify, or disprove,
that.

Is that something you'll undertake to find/fix/communicate? Or is it left to others?

If it works with 0.12.1 and fails with an unreleased SVN trunk version, I'd say
most likely the developer doesn't consider SVN trunk stable enough to use right
now.  

You can raise this with them and provide a copy of the source files (sa-compile
--keep-tmps would be useful here) if you like; we do not, in general, keep up to
date with re2c trunk, instead using what he considers release-quality.  That's
typically good advice ;)

Now that re2c 0.13.0 has been *released*, the problem as reported above continues.

sa-compile fails at,

...
scanner1.c: In function 'Mail_SpamAssassin_CompiledRegexps_body_0_scan1':
scanner1.c:6916: error: parse error at end of input
scanner1.c:3899: error: label 'yy3211' used but not defined
make: *** [scanner1.o] Error 1
command failed! at /usr/local/bin/sa-compile line 282.
COMPILE DONE

ok, sounds like we have a problem then!(In reply to comment #7)
> Now that re2c 0.13.0 has been *released*, the problem as reported above continues.

ok, that's a problem then!  I can't repro the bug with 0.13.0 and SA 3.2.2 on
Linux/x86, so it may be a platform-specific, or ruleset-specific problem.

What rulesets do you have installed?  just the SA default, or additional SARE ones?

I would recommend running "sa-compile --sudo --keep-tmps" and once it fails, tar
up the temporary dir mentioned in the last line of the output, e.g.:

temporary dir left due to --keep-tmps: /tmp/.spamassassin3353b3oFKDtmp

also, take a copy of the output on stdout from sa-compile.  Attach both here,
and possibly as a new bug report at re2c.org (although it may be best to check
it out here first).

It would be really helpful if you could cp /usr/share/spamassassin ~/tstrules,
then gradually rm rule files in ~/tstrules, running "sa-compile --sudo -C
~/tstrules" after each one, until you have a minimal ruleset that still exhibits
the bug.

> ok, that's a problem then!  I can't repro the bug with 0.13.0 and SA 3.2.2 on
> Linux/x86, so it may be a platform-specific, or ruleset-specific problem.

oh yeah -- or with SA trunk either.

> ok, sounds like we have a problem then!(In reply to comment #7)

> ok, that's a problem then!  I can't repro the bug with 0.13.0 and SA 3.2.2 on
> Linux/x86, so it may be a platform-specific

here,

osx 10.4.10
perl 588
re2c 0.13.0
sa-compile --version
	SpamAssassin version 3.2.3-r559432

fwiw, this is 100% reproducible on 6 similar boxes.  so, at least it's not
single-box-weirdness.

also, fyi, new release version, re2c 0.12.2 "works" fine ...

>, or ruleset-specific problem.
> 
> What rulesets do you have installed?  just the SA default,

of COURSE not.

that would be too easy ;-)

> or additional SARE ones?

atm,

SA-distro rules
+ SARE-rules
 {
   70_sare_obfu.cf.sare.sa-update.dostech.net
   72_sare_redirect_post3.0.0.cf.sare.sa-update.dostech.net
   70_sare_evilnum0.cf.sare.sa-update.dostech.net
   70_sare_evilnum1.cf.sare.sa-update.dostech.net
   70_sare_bayes_poison_nxm.cf.sare.sa-update.dostech.net
   70_sare_header.cf.sare.sa-update.dostech.net
   70_sare_header_eng.cf.sare.sa-update.dostech.net
   99_sare_fraud_post25x.cf.sare.sa-update.dostech.net
   70_sare_spoof.cf.sare.sa-update.dostech.net
   70_sare_random.cf.sare.sa-update.dostech.net
   70_sc_top200.cf.sare.sa-update.dostech.net
   70_sare_oem.cf.sare.sa-update.dostech.net
   70_sare_unsub.cf.sare.sa-update.dostech.net
   70_sare_uri.cf.sare.sa-update.dostech.net
   70_sare_specific.cf.sare.sa-update.dostech.net
   70_sare_oem.cf.sare.sa-update.dostech.net
   70_sare_html.cf.sare.sa-update.dostech.net
   70_sare_genlsubj.cf.sare.sa-update.dostech.net
   72_sare_bml_post25x.cf.sare.sa-update.dostech.net
   70_sare_stocks.cf.sare.sa-update.dostech.net
   99_FVGT_Tripwire.cf.sare.sa-update.dostech.net
   bogus-virus-warnings.cf.sare.sa-update.dostech.net
 }
+ fuzzy-ocr
+ botnet
+ freemail
+ kam

> I would recommend running "sa-compile --sudo --keep-tmps" and once it fails, tar
> up the temporary dir mentioned in the last line of the output, e.g.:
> 
> temporary dir left due to --keep-tmps: /tmp/.spamassassin3353b3oFKDtmp
> 
> also, take a copy of the output on stdout from sa-compile.  Attach both here,
> and possibly as a new bug report at re2c.org (although it may be best to check
> it out here first).
> 
> It would be really helpful if you could cp /usr/share/spamassassin ~/tstrules,
> then gradually rm rule files in ~/tstrules, running "sa-compile --sudo -C
> ~/tstrules" after each one, until you have a minimal ruleset that still exhibits
> the bug.

well, snort!

i'll start the process in-between meetings ... will post when done.

The announcements from re2c.sourceforge.net :

# re2c 0.12.2 released   2007-06-27
# re2c 0.13.0 released   2007-06-25
# re2c 0.12.1 released   2007-05-24

Yes, that's right, 0.12.2 released two days after 0.13.0, with the release notes
for 0.12.2 saying

Date: 2007-06-27 10:46
Summary: re2c 0.12.2 released

This new stable version of re2c fixes issue on Mac OS X (See issue #1743180
fwrite with 0 length crashes on OS X). 

So I'll close this bug as a WONTFIX

> This new stable version of re2c fixes issue on Mac OS X (See issue #1743180
> fwrite with 0 length crashes on OS X). 
> 
> So I'll close this bug as a WONTFIX

Well, it "worked" for awhile :-/  As I'n not sure this is/isn't related, I'll
re-open *here* for the moment ... 

Doing some updating/checking, after a recent,

  sudo -u sa_admin sa-update
  --channelfile ${CONF_DIR}/SARE-ch.conf \
  --gpgkey 856AA88A \

with either of,

  re2c v0.12.3
  re2c v0.13.1

a subsequent,

  sa-compile --sudo -D

fails (?) at,

  ..
  cd /tmp/.spamassassin10158OCBjw9tmp
  cd Mail-SpamAssassin-CompiledRegexps-body_0
  Wide character in print at /usr/local/sa/bin/sa-compile line 383, <$fh> line 2204.
  Wide character in print at /usr/local/sa/bin/sa-compile line 383, <$fh> line 2205.
  Wide character in print at /usr/local/sa/bin/sa-compile line 383, <$fh> line 2206.
  Wide character in print at /usr/local/sa/bin/sa-compile line 383, <$fh> line 4722.
  re2c -i -b -o scanner1.c scanner1.re
  re2c: error: line 41, column 38: can't find symbol
  command failed! at /usr/local/sa/bin/sa-compile line 286, <$fh> line 7152.
  COMPILE DONE

RE-checking latest announcements from re2c.org,

  Changelog
  2007-08-24: 0.13.1
    * Added custom build rules for Visual Studio 2005 (re2c.rules). (William
Swanson)
    * Fixed issue with some compilers.
    * Fixed #1776177 Build on AIX.
    * Fixed #1743180 fwrite with 0 length crashes on OS X.
  2007-08-24: 0.12.3
    * Fixed issue with some compilers.
    * Fixed #1776177 Build on AIX.
    * Fixed #1743180 fwrite with 0 length crashes on OS X.
  2007-06-26: 0.12.2
    * Fixed #1743180 fwrite with 0 length crashes on OS X.
  2007-06-24: 0.13.0
    * Added -c and -t to generate scanners with (f)lex-like condition support.
    * Fixed issue with short form of switches and parameter if not first switch.
    * Fixed #1708378 segfault in actions.cc.
  2007-05-23: 0.12.1
    * Fixed #1711240 problem with '"' and 7F on EBCDIC plattforms.


and dropping BACK to a previously working,

  re2c v0.12.2

the error REMAINS!  :-/

Fyi, since reporting above, I've bumped SA version,

  sa-compile --version
-    SpamAssassin version 3.2.3-r559432
+    SpamAssassin version 3.2.4-r564346

Something in SA that's upsetting re2c again? Other?

I found the *source* of the issue --
It appears to be JMASON's "sought.rules.yerp.org" channel file.

Whether the problem is *caused* by "bad data", re2c or sa-compile, I simply
don't know.

As evidence, I've sa-compiled with "--keep-temps".

Noting the error,

	re2c -i -b -o scanner1.c scanner1.re
	re2c: error: line 41, column 38: can't find symbol

Line41 in the resultant scanner1.re is,

    " - expirience of programming tcp\""ip-based applications. -"           
{RET("__SEEK_NXNZCJ");}

If I remove the somewhat suspect-looking,

	\""

in the middle, i.e.,

    " - expirience of programming tcp ip-based applications. -"           
{RET("__KAM_VIAGRA9A __SEEK_NXNZCJ");}

then,

	re2c -i -b -o scanner1.c scanner1.re

now completes without error.

Hm.

Checking,

	grep -rlni "expirience of programming tcp" .
		./Updates/3.002004/sought_rules_yerp_org/20_sought.cf

I note that the source of that stanza is Justin Mason's "sought.rules.yerp.org"
update channel.  Yes, I do install/update that channel.

As an experiment, I

	rm -rf ./Updates/3.002004/sought_rules_yerp_org

and disabler that update channel.

A subsequent re-update & re-compile now finishes,

	...
	sudo rm -rf /tmp/.spamassassin19501hkCdjbtmp
	[19501] dbg: plugin: Mail::SpamAssassin::Plugin::Check=HASH(0x1a7dbf0)
implements 'finish_tests', priority 0
	[19501] dbg: plugin: Mail::SpamAssassin::Plugin::MIMEHeader=HASH(0x1be1aac)
implements 'finish_tests', priority 0
	COMPILE DONE
	%

without error.

I can also verify that -- with 'sought' channel removed/disabled -- all's OK
with re2c versions 0.12.2, 0.12.3 & 0.13.1.

that's bug 5493: http://issues.apache.org/SpamAssassin/show_bug.cgi?id=5493

BTW, it would be better not to re-open bugs.  I cannot now mark this as a
duplicate of that bug, because the bug report described in comments 1 to 11 is a
separate issue entirely.