Created attachment 2310 [details]
rules file used to reproduce the hang

Created attachment 2311 [details]
mass-check.cf used during reproduce of this hang

Even zipped, the single-week corpus file is too large to upload to bugzilla. 
Will split file until I have a smaller corpus file that reproduces...

Created attachment 2312 [details]
mbox file (not zipped) that reproduces the hang

to check: does the hang occur if you're not using the attached rules (ie: just
the SA standard rules)?

Yes.  Ensured that only distribution rules were in the /rules/ directory. 
Placed this corpus file into /masses/.  Used the command
> perl ./mass-check -p=/home/Owner/Mail-SpamAssassin-3.0.0/masses -j 1 --
loghits --mid --mbox ./bug3748.mbox.txt >spam.log.bug3748
mass-check hangs the same way (generating no output to the stdout 
spam.log.bug3748 file, or anywhere else I can find). Running top while this 
happens, I see perl at the top of the list for a short while, 99% of cpu, then 
it drops to zero after using about 1:13 of cpu time.

<grrr>

I figured out what the problem is:

------=DreamInTech.nfra21WAS2.Mail.Engine40fd71588f855
Content-Type: message/delivery-status

------=DreamInTech.nfra21WAS2.Mail.Engine40fd71588f855


the message subparsing is looking for input, but it's a blank part so it's
looking to STDIN.

<grumble grumble>   patch forthcoming.

Created attachment 2313 [details]
patch

this patch disables message/* subparsing if the part has no decoded value, just
adding as a leaf node instead of a subtree.

putting in review state.  passes make test for me, solves reproduced issue.

+1

Just an FYI: confirmed, the patch fixes the problem here. Thanks. 

+1

committed.  r43361

*** Bug 3763 has been marked as a duplicate of this bug. ***

*** Bug 3764 has been marked as a duplicate of this bug. ***

Apparently one codepath leading to the problem was fixed, but not the
underlying problem itself (e.g. when M::S::parse is called with an
empty string (or a '0') as a message it still hangs, waiting on STDIN).

The code in Message.pm still conflicts with documentation:

Docs on Mail::SpamAssassin::parse says:
  Parse will return a Mail::SpamAssassin::Message object with just the
  headers parsed.  When calling this function, there are two optional
  parameters that can be passed in: $message is either undef (which will
  use STDIN), ...

Docs in Mail::SpamAssassin::Message::new says:
  C<message> is either undef (which will use STDIN), a scalar ...

while the actual code in Message::new treats the supplied value
as a boolean instead of testing for defined as claimed by the docs:
  my $message = $opts->{'message'} || \*STDIN;

As we have seen in other occasions (Bug 5965), treating user-supplied
data as a Perl boolean is generally bad practice.

The above statement should have been:
  my $message = defined $opts->{'message'} || \*STDIN;
to match the documentation and to avoid potential further
problems with hanging calls (Bug 3764).

Likewise, the code in Mail::SpamAssassin::Message::parse_body
treats a user-supplied string as a boolean in an attempt to
prevent the underlying error:
  # bug 5051: sometimes message/* parts have no content, and we get
  # stuck waiting for STDIN, which is bad. :(
  if ($toparse->[0]->{'decoded'}) {

I think it should be testing $toparse->[0]->{'decoded'} for being
equal to an empty string, or perhaps for being defined (I should
check what result the decode() can return).

Reopening...

> Docs in Mail::SpamAssassin::Message::new says:
>   C<message> is either undef (which will use STDIN), a scalar ...
> while the actual code in Message::new treats the supplied value
> as a boolean instead of testing for defined as claimed by the docs

> Likewise, the code in Mail::SpamAssassin::Message::parse_body
> treats a user-supplied string as a boolean

Ok, fixed both in trunk:

r732591 | mmartinec | 2009-01-08 03:17:57 +0100 (Thu, 08 Jan 2009) | 1 line
bug 3748, take 2

r732588 | mmartinec | 2009-01-08 02:44:10 +0100 (Thu, 08 Jan 2009) | 1 line
hmm, back up the mess

r732582 | mmartinec | 2009-01-08 02:21:41 +0100 (Thu, 08 Jan 2009) | 1 line
bug 3748: match code to docs: test $opts->{message} for defined instead of treating it as a boolean


Sorry for the bad fix mess in r732582.

this is now fixed, right Mark?

> this is now fixed, right Mark?

Yes, it is fixed in 3.3 trunk.