Xref: utzoo comp.unix.microport:3692 comp.bugs.misc:257 comp.bugs.sys5:1083 Path: utzoo!utgpu!attcan!lsuc!atha!lyndon From: lyndon@cs.AthabascaU.CA (Lyndon Nerenberg) Newsgroups: comp.unix.microport,comp.unix.i386,comp.bugs.misc,comp.bugs.sys5 Subject: Re: UUCP PROBLEM ON MICROPORT V/386 3.0e Summary: Divide by zero strikes again. Message-ID: <1034@aurora.AthabascaU.CA> Date: 9 Aug 89 01:11:56 GMT References: <119146@sun.Eng.Sun.COM> Followup-To: comp.bugs.sys5 Organization: Athabasca University Lines: 49 [ Followups directed to comp.bugs.sys5 since this is a generic bug in SVR3.1 ... ] In article <119146@sun.Eng.Sun.COM> williamt@sun.UUCP (William A. Turnbow) writes: > 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). Have you tested your 120 character hypothesis? We ran into this a while ago, and it turned out to be a divide by zero that occurred when uucico transfered a zero length (exactly) file. (Who transfers zero length files, anyway!?! *I* do, to force polls when I can't directly execute uucico.) The fix to statlog.c is trivial (if you have source) : *** statlog.c.old Tue Aug 8 18:57:35 1989 --- statlog.c Tue Aug 8 18:58:38 1989 *************** *** 26,32 **** bytes1000 = bytes * 1000; (void) sprintf(text, "%s %lu / %lu.%.3u secs, %lu bytes/sec", direction, bytes, millisecs/1000, millisecs%1000, ! bytes1000/millisecs ); CDEBUG(4, "%s\n", text); syslog(text); } --- 26,32 ---- bytes1000 = bytes * 1000; (void) sprintf(text, "%s %lu / %lu.%.3u secs, %lu bytes/sec", direction, bytes, millisecs/1000, millisecs%1000, ! bytes1000 == 0L ? 0L : bytes1000/millisecs ); CDEBUG(4, "%s\n", text); syslog(text); } The bug is present on the SVR3.1 porting base tape, so it may be in a lot of vendor's implementations. I haven't checked to see if it's present in the 3.2 porting base. -- Lyndon Nerenberg VE6BBM / Computing Services / Athabasca University {alberta,decwrl,ncc}!atha!lyndon || lyndon@cs.AthabascaU.CA CTIX-USERS has moved to: ctix-users[-request]@cs.AthabascaU.CA