fine on Solaris x86 with perl 5.8.6.
fine on MacOS X with perl 5.8.8.
bug happens with Linux (Ubuntu gutsy), perl 5.8.8.
bug happens with Linux (Ubuntu hardy 8.04.1), perl 5.8.8.

looks like a platform-specific perl bug. I also can't repro it with this test script: http://taint.org/x/2008/bug5985scr , despite the "strace" output looking pretty similar.

This is a hacky workaround, checking eof() if an error condition is indicated:

: jm 65...; svn commit -m "bug 5985: avoid spurious 'message: error reading: Bad file descriptor' error during normal use" lib
Sending        lib/Mail/SpamAssassin/Message/Node.pm
Transmitting file data .
Committed revision 698119.

However, maybe we should just skip the error check entirely; this workaround adds an additional read() syscall that is unnecessary, and may just hide "real" bugs anyway, since hte doco says that eof() returns 1 if the FH is not open, too.

feel free to try to find a better fix... ;)

> fine on Solaris x86 with perl 5.8.6.
> fine on MacOS X with perl 5.8.8.
> bug happens with Linux (Ubuntu gutsy), perl 5.8.8.
> bug happens with Linux (Ubuntu hardy 8.04.1), perl 5.8.8.
> 
> looks like a platform-specific perl bug. I also can't repro it with this test
> script: http://taint.org/x/2008/bug5985scr , despite the "strace" output
> looking pretty similar.

A Perl bug on Linux, see:

  http://rt.perl.org/rt3//Public/Bug/Display.html?id=39060

Some Linux distributions set env. var. PERLIO="stdio".
Dropping it (unset PERLIO, or setting it to "") avoids the bug.

Sending        lib/Mail/SpamAssassin/Message/Node.pm
Sending        lib/Mail/SpamAssassin/Message.pm
Committed revision 699006.

Message.pm and Message/Node.pm: replace line-by-line reading by
sysread + split, thus avoiding a Perl i/o bug on some platforms
( http://rt.perl.org/rt3//Public/Bug/Display.html?id=39060 ,
SA Bug 5985), while also providing a little speedup (10..25%)
on reading a message.

Looks like M::SA::AI has the same issue in a few spots.

status:  14% ham: 11     spam: 465    date: 2008-08-04   now: 2008-10-01 05:11:00
status:  15% ham: 12     spam: 498    date: 2008-08-04   now: 2008-10-01 05:11:01
error reading: Bad file descriptor at /home/dos/sa-mass-check/nightly_mass_check/masses/../blib/lib/Mail/SpamAssassin/ArchiveIterator.pm line 380, <INPUT> line 2783.


There are probably other areas where the same thing is done (sa-learn perhaps).

> lib/Mail/SpamAssassin/ArchiveIterator.pm line 380, <INPUT> line 2783.
> There are probably other areas where the same thing is done (sa-learn perhaps).

Do you have the environment variable PERLIO explicitly set?
To a non-default perl setting? If yes, could you please unset it
and see if ArchiveIterator.pm still hits that perl bug.

No, I do not.  Stock Fedora Core 6 Perl 5.8.8.

Committed revision 702559:
  Bug 5985: avoid Perl I/O bug by replacing line-by-line reading
  with read() where suitable, or play down the EBADF status in
  other places and only report it as dbg instead of a die.
  Also localized a couple of file handles where I came across them.

(In reply to comment #7)
> Committed revision 702559:
>   Bug 5985: avoid Perl I/O bug by replacing line-by-line reading
>   with read() where suitable, or play down the EBADF status in
>   other places and only report it as dbg instead of a die.
>   Also localized a couple of file handles where I came across them.

will that fix Daryl's bug, do you think?

(asking because I think I may be running into it sporadically -- although I haven't been able to spot a mass-check where it's occurred for me recently.)

> will that fix Daryl's bug, do you think?

I believe it does. The read() is not prone to this perl bug
and as a bonus is even faster where we can afford reading
in chunks instead of line-by-line (e.g. when the whole file
is intended to end up in memory anyway, or when copying it
to another file). The remaining cases of line-by-line reads
now report EBADF only at a dbg level.

I did the missed cases in sa-compile.raw and sa-learn.raw today,
revision 702797. The only module still without this playing down
of severity is Client.pm.

I opened a new perlbug [perl #59550], this time against perl 5.10 and
as a general case, not as a missing NL in the last line [perl #39060].
Still waiting for some response.
 
> (asking because I think I may be running into it sporadically -- although I
> haven't been able to spot a mass-check where it's occurred for me recently.)

Still after my yesterday's check-in?

(In reply to comment #9)
> > (asking because I think I may be running into it sporadically -- although I
> > haven't been able to spot a mass-check where it's occurred for me recently.)
> 
> Still after my yesterday's check-in?

no, it was at least a week ago.

(In reply to comment #8)
> will that fix Daryl's bug, do you think?

Yes, this fixed the issue I was having.  Thanks Mark!

I'll leave this open since there's still Client.pm to take care of.

> Yes, this fixed the issue I was having.  Thanks Mark!
> 
> I'll leave this open since there's still Client.pm to take care of.

Ok, I'll deal with it after the alpha release.

Btw, few weeks ago I got a report that the Perl I/O bug
is finally fixed in version 10, so the fix will probably
appear with the next Perl release.

> > I'll leave this open since there's still Client.pm to take care of.
> Ok, I'll deal with it after the alpha release.

  Bug 5985 - Client.pm: deal gracefully with a Perl I/O bug which may
  return status EBADF at eof; add: use strict; use warnings; use re 'taint'
Sending        lib/Mail/SpamAssassin/Client.pm
Committed revision 793156.


Btw, is there any test for this module? Wouldn't hurt.

> Btw, is there any test for this module? Wouldn't hurt.

Replying to myself: yes there is, it's the spamd_client.t,
and it passes all the tests on my host (perl 5.10.0).
Closing.