Xref: utzoo comp.unix.microport:3665 comp.bugs.misc:251
Path: utzoo!utgpu!watmath!att!pacbell!ames!apple!sun-barr!newstop!sun!athena1!williamt
From: williamt@athena1.Sun.COM (William A. Turnbow)
Newsgroups: comp.unix.microport,comp.unix.i386,comp.bugs.misc
Subject: Re: UUCP PROBLEM ON MICROPORT V/386 3.0e
Keywords: uucp bug core uucico
Message-ID: <119146@sun.Eng.Sun.COM>
Date: 2 Aug 89 18:07:51 GMT
Sender: news@sun.Eng.Sun.COM
Reply-To: williamt@sun.UUCP (William A. Turnbow)
Lines: 28


	Microport shipped HDB uucp.  The problem was not with debug, but
was(is) when the first file to be transfered is short.  Now short can
seemingly be anything under about 120 chars or so, maybe a bit longer,
though I suspect if it is much over that, it will not get the timing
error.

	The error comes in the statistics gathering section where it tries to
compute the number of chars transfered per second (cps).  For some reason,
if the first file is short, it seems to pretty consistently come up with
a time of 0 (measured in milliseconds).  This ends up getting a
divide by zero error and a core dump in the directory of the system
uucp was sending to at the time.

	The only workaround I have come up with so far is running uucp under
sdb.  Continuing to hit the 'c' key to continue (you get several ALARM,
SIG 14's) past the breaks generated by the ALARMS, until you get to the
one caused by the divide by zero.  Then you do an 'x' command to see
the offending instruction: div 10[dbp],dax, or something similar.  The
value at location dbp+10 is zero and needs to be non-zero.  Patching it
at run-time with a value of 1 with <addr>!1, I believe, then continuing,
allows uucp to continue, and the rest of the files go uninterrupted.

	I supposed some patching of the binary source to zero out that divide
might be a easier work-around, since it wouldn't require manual intervention
everytime it happens, but I haven't gotten around to doing the research.

-wat-