Xref: utzoo comp.unix.microport:3432 comp.bugs.misc:230
Path: utzoo!attcan!uunet!cs.utexas.edu!rutgers!apple!oliveb!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: <110505@sun.Eng.Sun.COM>
Date: 15 Jun 89 23:21:48 GMT
References: <242@atbull.UUCP>
Sender: news@sun.Eng.Sun.COM
Reply-To: williamt@sun.UUCP (William A. Turnbow)
Organization: Sun Microsystems, Mountain View
Lines: 23


    This is a known problem with uports uucico.  I reported it sometime
ago (about 3-4 months ago).  It seems, there is a place in uucico, that
for statistics purposes, calculates the bps rate.  In my particular case
it only happened on the first file and if that file was short (say < 200
characters, I think the max I saw was around 150, but it's been a while).
For some reason, the time in the Bytes/time calculation was zero.  This
caused a divide by zero error resulting in the core dump.

	The only way to kludge around the problem was to find and delete
the offending 'too short' file, or like I did, use sdb (or whatever
the debuggers name is), and run uucico under the debugger.  When it
got to the bad statement, it trapped into the debugger, at which point
I patched a non-zero value (like 1) into the denominator (the time
variable).  The report came out with some fantastic speed of BPS (like
around 200K BPS), and then the rest of the transfers completed normally.

	I suppose all of the offending calculation code could just be
nop'ed out, but that would kill all statistic reporting.  Of course then
uucico would be *seemingly* reliable.  I suppose it might be
worth it if no other solution is available.

-wat-