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.commike@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