From:	SMTP%"MX-List%WKUVX1.BITNET@ULKYVM.LOUISVILLE.EDU"  2-JUN-1993 12:25:17.65
To:	EVERHART
CC:	
Subj:	The fix for UUCP_MAILSHR (assuming you have the sources and compiler)

X-ListName: Message Exchange Discussion List <MX-List@WKUVX1.BITNET>
Warnings-To: <>
Errors-To: list-mgr@WKUVX1.BITNET
Sender: list-mgr%WKUVX1.BITNET@ULKYVM.LOUISVILLE.EDU
Date: Wed, 02 Jun 1993 11:19:32 CDT
From: Hunter Goatley <goathunter%WKUVX1.BITNET@ULKYVM.LOUISVILLE.EDU>
Reply-To: MX-List%WKUVX1.BITNET@ULKYVM.LOUISVILLE.EDU
To: mx-list@WKUVX1.BITNET
Message-ID: <0096D6C0.414E16E0.16812@WKUVX1.BITNET>
Subject: The fix for UUCP_MAILSHR (assuming you have the sources and compiler)

I found my original post from February about the UUCP_MAILSHR problem,
including the instructions for fixing it.  Note that you'll need the
sources and a Pascal compiler to fix it.

Hunter
------
Hunter Goatley, VMS Systems Programmer, Western Kentucky University
goathunter@WKUVX1.BITNET (or goathunter%wkuvx1.bitnet@ULKYVM.LOUISVILLE.EDU)
---------------------------------------------------------------------------
Date: Sun, 28 Feb 1993 00:48:45 CST
From: Hunter Goatley <goathunter@WKUVX1.BITNET>
Subject: RE: mx -> uucp hung in compute bound loop

munroe@DMC.COM writes:
>
>I have a queue entry that causes the MX -> UUCP process to go into an infinite
>loop.  The only way out is to kill the process, cancel the entry, and restart
>the process manually (mcp shut is ineffective).  This bug has shown up
>occasionally with 3.1 and is data dependent, particular messages cause the
>problem.  I'm sending a VMSSHARE of the queue entry causing the problem under
>seperate header.  Hope you can find this one.
>
I did.

As I mentioned the other day, I thought the problem was not an MX
problem but was instead a DECUS UUCP problem.  Well, I was right---it
*is* a DECUS UUCP problem, and it's an incredibly subtle bug!

When a file is sent through UUCP_MAILSHR (using, say, SEND/NOEDI file
or, in the case of MX->uucp, MAIL/PROTOCOL=UUCP_MAILSHR filename....),
UUCP_MAILSHR makes sure that every line is wrapped to produce lines
that are no longer than 255 characters.  When a line is read that is
longer than 255 characters, it starts at the 255th character and
starts looking backwards for either a space or a linefeed.  When
either is found, that point becomes the place where the line is broken
for wrapping.

The MX->uucp looping problem only occurs when a binary file is sent
through that contains lines with substrings longer than 255 characters
with no space or linefeed in them *except* the very first character!
For example:

   0            40                   320    512
   Word ... Word ....nospaceorlinefeed. ..........

UUCP_MAILSHR would try to break this line into multiple lines.  The
first line would be "Word ..." (up to the 40th byte), and then, the
way the code is written, it will loop forever writing out 0 bytes
because it found a blank at offset 1, which set a "done" flag to true,
then decremented the number of bytes from 1 to 0.  The check after
that loop says, "if ((bytes = 0) and (not done) then bytes := 255;".
Well, in this case, bytes is 0 by done is true, so bytes stays 0 and
the later, when recalculating bytes left, we subtract 0 and reprocess
the characters 40-294.  Voila!  Infinite loop!

It's easy to fix---in UUPC_MAIL.PAS in procedure put_text, change the
check above ("if ((bytes = 0)....") to just "if (bytes = 0) then bytes
:= 255;".  That'll write out the line with a leading blank.  You could
try to handle this case specifically, but I see no point in doing so.

On Monday, I'll let the UUCP guys (and MX-List) know about this bug.

Hunter
------
Hunter Goatley, VMS Systems Programmer, Western Kentucky University
goathunter@WKUVX1.BITNET (or goathunter%wkuvx1.bitnet@UKCC.UKY.EDU)
