http://bugzilla.spamassassin.org/show_bug.cgi?id=3917
------- Additional Comments From [EMAIL PROTECTED] 2004-11-01 10:39 -------
I have a workaround that tests ok, but I am not submitting a patch because I
don't think it is a workable solution. Instead I'm putting it in this comment in
the hopes that someone has some idea what it implies about the problem and what
might be done about it.
Remember, this only seems to happen in Cygwin. I can't say if it Win32 would
also do it because I have not distilled the problem into a standalone example
and Win32 doesn't run spamd.
The problem seems to be that in Cygwin we cannot reliably send strings of around
30,000 bytes over a tcp socket. If we do some do not arrive and the packet loss
is not corrected by the tcp protocol as it is supposed to.
spamd sends the entire message using a single call to print $client "some
header" $msg_resp;
Without a standalone test I can't say if it happens at an integer overflow
boundary of 32767 or if it is a smaller number. The error is sporadic, so it is
not a simple buffer or integer overflow. My test is to send the same message to
spamd 10 times in a row with a 5 second sleep between them and checking the
return code. With my 38k test message about two to four of the times the return
code from spamc -x is 76.
If I change that to print $client "some header"; followed by the followiong
code, which slleps for a second after every 10,000 bhytes it works fine.
If I use a $client->flush() instead of sleep(1) it still breaks.
Does anyone have any insight?
This goes in spamd.raw approximately at line 1176 and comes after removing the
$msg_resp from each of the preceding print lines.
my @segs = unpack("a10000" x ($msg_resp_length/10000) . " a*", $msg_resp);
foreach my $sg (@segs) {
print $client $sg;
sleep(1);
}
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
