[comp.unix.i386] UUCP PROBLEM ON MICROPORT V/386 3.0e

ee@atbull.UUCP (Erwin Eder ) (06/16/89)

HEEEEELP !!!!

    Please could any kind uucp-guru out there enlighten me concerning the
following problem :

Configuration :
 o) 2 BULL Micral 75 (386/AT's) running Microport V/386 3.0e + DOS-Merge
 o) Intelliport AT8 (8 serial lines for terminals & printers)
 o) Connection via ttyM01 on both machines (works fine with kermit,cu,...)
 o) Speed 9600 Baud (direct connaction - should be modem in future)
 o) Systems/Devices/Permissions seem OK

Problem :
  When running  uucp  from either machine there happen strange things
  in about one of 5 to 10 cases.  A strange file named 'core' is left
  in '/usr/spool/uucp/bull2/'. It is 'not a core file' (/usr/bin/sdb)
  but 'english text'  ( /bin/file :-).  It seems to be a strange kind
  of binary (badly formed core dump of uucico ??) .  When using Uutry
  there is a message  'Uutry: XXXX abort - core dumped'  (  XXXX is a
  decimal  number (PID?) ).  This happens about once from five to ten
  'uucp's  (cannot find out when or caused by what) on both Machines.

Many thanx for any pointers

	Erwin Eder (ee@atbull)

-- 
+---/~~~~\---------------+--------------------------------------------+
|  /      \  <-- this is |  and this    uunet!mcvax!tuvie!atbull!ee   |
|   \____/       a tree. |  is me -->     In-Real-Life Erwin Eder     |
+-----||-----------------+--------------------------------------------+

williamt@athena1.Sun.COM (William A. Turnbow) (06/16/89)

    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-

bill@twwells.com (T. William Wells) (06/17/89)

In article <242@atbull.UUCP> ee@atbull.UUCP (Erwin Eder ) writes:
:   When running  uucp  from either machine there happen strange things
:   in about one of 5 to 10 cases.  A strange file named 'core' is left
:   in '/usr/spool/uucp/bull2/'. It is 'not a core file' (/usr/bin/sdb)
:   but 'english text'  ( /bin/file :-).  It seems to be a strange kind
:   of binary (badly formed core dump of uucico ??) .  When using Uutry
:   there is a message  'Uutry: XXXX abort - core dumped'  (  XXXX is a
:   decimal  number (PID?) ).  This happens about once from five to ten
:   'uucp's  (cannot find out when or caused by what) on both Machines.

I don't know what your problem is, but file on a core file really
does say `English text'. It's a bug in file. So look at the core
file, but I'll bet it's uucico.

Question: what does the log file say when you get these? And did
you try running uucico with all the debugging on?

---
Bill                    { uunet | novavax | ankh | sunvice } !twwells!bill
bill@twwells.com

mike@cimcor.mn.org (Michael Grenier) (06/19/89)

From article <780@redsox.bsw.com>, by campbell@redsox.bsw.com (Larry Campbell):
> There was also a really irritating bug in the uucico shipped with
> Microport System V/AT, which was that uucico dumped core if the calling
> system's uucico was running with the debug flag!  (uucico -xn, for any
> nonzero value of n).  We reported this to Microport and they said they
> knew about it and had no intention of fixing it.  (This was long before
> they went belly-up.)


Wooo....hold on there cowboy. One reason Microport may not have bothered
to fix it is that they were/are shipping the Honey Damber upgrade
which is a much better UUCP and the uucico program does not dump core
with the debugging. The cost of the upgrade was only about $20 to $30
(I don't remember). In fact, it was free if you downloaded it from their
BBS...If nothing else, spend the $20 and buy Microport's BBS software
disks which should have it.

Trying to get UNIX programs to run on braindamaged 64K segmented machines
with 16 bit integers is not trivial. Bear in mine that Microport got
the broken programs from AT&T and they fixed many of them.

> I don't know if they shipped the same braindead uucico with their
> 386 product, 

No. The AT&T System V/386 product ships with HDB UUCP.

    -Mike Grenier
    mike@cimcor.mn.org

williamt@athena1.Sun.COM (William A. Turnbow) (06/19/89)

In article <8389@killer.DALLAS.TX.US> wnp@killer.Dallas.TX.US (Wolf Paul) writes:
>Does Uport V/386 use V2 uucp, or HDB (BNU) uucp? And if both, which 
>version does this bug pertain to?
---------
	This was (is?) in HDB uucp.  Is HDB public domain, or where was it
developed?  (Wondering if I could get source and recompile with the error
fixed).

-wat-

det@hawkmoon.MN.ORG (Derek E. Terveer) (06/21/89)

In article <110921@sun.Eng.Sun.COM>, williamt@athena1.Sun.COM (William A. Turnbow) writes:
> In article <8389@killer.DALLAS.TX.US> wnp@killer.Dallas.TX.US (Wolf Paul) writes:
> >Does Uport V/386 use V2 uucp, or HDB (BNU) uucp? And if both, which 
> >version does this bug pertain to?
> ---------
> 	This was (is?) in HDB uucp.  Is HDB public domain, or where was it
> developed?  (Wondering if I could get source and recompile with the error
> fixed).

Hdb was, i believe, developed by peter honeyman working at at&t and is not in
the public domain.
-- 
Derek Terveer 	    det@hawkmoon.MN.ORG || ..!uunet!rosevax!elric!hawkmoon!det
		    w(612)681-6986   h(612)688-0667

"A proper king is crowned" -- Thomas B. Costain

berry@lll-crg.llnl.gov (Berry Kercheval) (06/23/89)

In article <989@hawkmoon.MN.ORG>, det@hawkmoon (Derek E. Terveer) writes:
>In article <110921@sun.Eng.Sun.COM>, williamt@athena1.Sun.COM (William A. Turnbow) writes:
>>  Is HDB public domain, or where was it
>> developed?
>Hdb was, i believe, developed by peter honeyman working at at&t and is not in
>the public domain.

It was in fact developed by peter honeyman, Dan Nowitz and Brian
Redman at AT&T.  peter is at U of Michigan now; Brian is at Bellcore
and I don't know about Dan.  They presented their results at a Usenix
about 5 years ago.
  HDB, or BNU as the often perverse AT&T marketing agents insist on
calling it, is most emphatically NOT public domain.

  --berry

campbell@redsox.bsw.com (Larry Campbell) (07/22/89)

There was also a really irritating bug in the uucico shipped with
Microport System V/AT, which was that uucico dumped core if the calling
system's uucico was running with the debug flag!  (uucico -xn, for any
nonzero value of n).  We reported this to Microport and they said they
knew about it and had no intention of fixing it.  (This was long before
they went belly-up.)

I don't know if they shipped the same braindead uucico with their
386 product, but if they did, and that's the problem you're having,
try not specifying the -x option at the calling end.
-- 
Larry Campbell                          The Boston Software Works, Inc.
campbell@bsw.com                        120 Fulton Street
wjh12!redsox!campbell                   Boston, MA 02146

wnp@killer.DALLAS.TX.US (Wolf Paul) (07/22/89)

In article <110505@sun.Eng.Sun.COM> williamt@sun.UUCP (William A. Turnbow) writes:


 >    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


Does Uport V/386 use V2 uucp, or HDB (BNU) uucp? And if both, which 
version does this bug pertain to?



-- 
Wolf N. Paul * 3387 Sam Rayburn Run * Carrollton TX 75007 * (214) 306-9101
UUCP:   {texbell, killer, dalsqnt}!dcs!wnp
DOMAIN: wnp@killer.dallas.tx.us or wnp%dcs@texbell.swbt.com

plocher%sally@Sun.COM (John Plocher) (07/23/89)

In article <780@redsox.bsw.com> campbell@redsox.UUCP (Larry Campbell) writes:
>Microport System V/AT, which was that uucico dumped core if the calling
>system's uucico was running with the debug flag! Microport said they
>knew about it and had no intention of fixing it.

This was because we had been shipping HDB uucp as a replacement for the 286
uucp and we always shipped HDB with the 386.  HDB uucp didn't have that problem.

   -John

williamt@athena1.Sun.COM (William A. Turnbow) (08/03/89)

	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-

tkevans@fallst.UUCP (Tim Evans) (08/03/89)

In article <780@redsox.bsw.com>, campbell@redsox.bsw.com (Larry Campbell) writes:
> There was also a really irritating bug in the uucico shipped with
> Microport System V/AT, which was that uucico dumped core if the calling
> system's uucico was running with the debug flag!

I have been running 2.4 ever since they released the upgrade from 2.2/2.3
and have _never_ seen this happen.  This is probably because I also
obtained from uPort their HDB UUCP package--available on diskette,
sans support, for $20 at that time.  I don't know the current situation
with respect to getting it, though.

-- 
UUCP:  ...!{rutgers|ames|uunet}!mimsy!aplcen!wb3ffv!fallst!tkevans
INTERNET:  tkevans%fallst@wb3ffv.ampr.org
OTHER: ...!attmail!fallst!tkevans
Tim Evans  2201 Brookhaven Court, Fallston, MD  21047   (301) 965-3286

lyndon@cs.AthabascaU.CA (Lyndon Nerenberg) (08/09/89)

[ 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