wwm@pmsmam.uucp (Bill Meahan) (05/30/90)
Since the latest distribution I've received from comp.mail.maps, my attempts to build a new pathalias database result in pathalias hanging forever while taking up about 4.5 MEGS of core. After spending far too much time chasing the problem, I've found that keeping u.usa.nm.1 out of the input stream solves(?) the problem. Apparently something in the lastest bunch of maps (which do NOT include nm.1 so far) is inconsistent with the Apr 25 version of u.usa.nm.1. The inconsistency apparently involves some US site(s) only since using only u.usa.* input makes the problem occur. Anyone else having this problem or have I got something messed up here?? Thanks for your advice. ____ -- Bill Meahan WA8TZG uunet!mailrus!umich!pmsmam!wwm I speak only for myself - even my daughter's cat won't let me speak for her!
mb@rex.cs.tulane.edu (Mark Benard) (05/30/90)
In article <1990May29.182555.27806@pmsmam.uucp> wwm@pmsmam.uucp (Bill Meahan) writes: >Since the latest distribution I've received from comp.mail.maps, my attempts >to build a new pathalias database result in pathalias hanging forever while >taking up about 4.5 MEGS of core. > >After spending far too much time chasing the problem, I've found that >keeping u.usa.nm.1 out of the input stream solves(?) the problem. Apparently >something in the lastest bunch of maps (which do NOT include nm.1 so far) >is inconsistent with the Apr 25 version of u.usa.nm.1. I had the same problem and tracked it down to an infinite loop involving bcsinc (in u.usa.ca.1) and rt1 (in u.usa.nm.1). Since the NM map was not changed recently and that CA map arrived last night, I concluded that it was a problem with bcsinc. Sure enough, commenting the bcsinc entry out of the CA map solved the problem. However, I do not know exactly why the loop occurred. Can anyone explain? Mark -- Mark Benard Department of Computer Science INTERNET & BITNET: mb@cs.tulane.edu Tulane University USENET: rex!mb New Orleans, LA 70118
randy@sdiego.uucp (Randy Yount) (05/30/90)
wwm@pmsmam.uucp (Bill Meahan) writes: >Since the latest distribution I've received from comp.mail.maps, my attempts >to build a new pathalias database result in pathalias hanging forever while >taking up about 4.5 MEGS of core. >After spending far too much time chasing the problem, I've found that >keeping u.usa.nm.1 out of the input stream solves(?) the problem. Apparently >something in the lastest bunch of maps (which do NOT include nm.1 so far) >is inconsistent with the Apr 25 version of u.usa.nm.1. >The inconsistency apparently involves some US site(s) only since using only >u.usa.* input makes the problem occur. >Anyone else having this problem or have I got something messed up here?? I'm having the same problem.....I tried Bill's work around and sure enough I could build the path database.
dplatt@coherent.com (Dave Platt) (05/30/90)
In article <1990May29.182555.27806@pmsmam.uucp> wwm@pmsmam.uucp (Bill Meahan) writes: > Since the latest distribution I've received from comp.mail.maps, my attempts > to build a new pathalias database result in pathalias hanging forever while > taking up about 4.5 MEGS of core. > > After spending far too much time chasing the problem, I've found that > keeping u.usa.nm.1 out of the input stream solves(?) the problem. Apparently > something in the lastest bunch of maps (which do NOT include nm.1 so far) > is inconsistent with the Apr 25 version of u.usa.nm.1. I ran into exactly the same problem. The version of pathalias I've been using (pathalias9) runs into a loop... it cycles repeatedly between nodes "rt1", "rt1.lanl.gov", and "bcsinc". rt1 and rt1.lanl.gov are one and the same, and there's a bi-directional private dead link between rt1 and bcsinc. I have no idea why this particular combination causes pathalias to loop... it seems that it should work properly. I was able to resolve (work around) the problem by downloading the latest version of pathalias from uunet (~/mail/pathalias.Z). This is a more recent version than the one I had been using... it supports the "adjust" clause, rather than the "-a" command-line option. It seems to "eat" the current maps distribution without any distress. Ghu alone knows why it fixes things, though. -- Dave Platt VOICE: (415) 493-8805 UUCP: ...!{ames,apple,uunet}!coherent!dplatt DOMAIN: dplatt@coherent.com INTERNET: coherent!dplatt@ames.arpa, ...@uunet.uu.net USNAIL: Coherent Thought Inc. 3350 West Bayshore #205 Palo Alto CA 94303
bblue@crash.cts.com (Bill Blue) (05/30/90)
In article <3438@rex.cs.tulane.edu> mb@rex.cs.tulane.edu (Mark Benard) writes: >In article <1990May29.182555.27806@pmsmam.uucp> wwm@pmsmam.uucp (Bill Meahan) writes: >>Since the latest distribution I've received from comp.mail.maps, my attempts >>to build a new pathalias database result in pathalias hanging forever while >>taking up about 4.5 MEGS of core. >> >>After spending far too much time chasing the problem, I've found that >>keeping u.usa.nm.1 out of the input stream solves(?) the problem. Apparently >>something in the lastest bunch of maps (which do NOT include nm.1 so far) >>is inconsistent with the Apr 25 version of u.usa.nm.1. > >I had the same problem and tracked it down to an infinite loop involving >bcsinc (in u.usa.ca.1) and rt1 (in u.usa.nm.1). Since the NM map was not >changed recently and that CA map arrived last night, I concluded that it was >a problem with bcsinc. Sure enough, commenting the bcsinc entry out of the >CA map solved the problem. > >However, I do not know exactly why the loop occurred. Can anyone explain? It's even more interesting when you consider that the bcsinc map entry hasn't changed since late August '89, and the rti entry hasn't changed since mid September '89. Something else seems to be bringing this to a head. --Bill Blue Southern California, Arizona Regional Uucpmap Coordinator UUCP: {nosc, ucsd, hplabs!hp-sdd}!crash!bblue ARPA: crash!bblue@nosc.mil INET: bblue@crash.cts.com
piet@eu.net (Piet Beertema) (05/30/90)
Since the latest distribution I've received from comp.mail.maps, my attempts to build a new pathalias database result in pathalias hanging forever while taking up about 4.5 MEGS of core. I had the same problem and tracked it down to an infinite loop involving bcsinc (in u.usa.ca.1) and rt1 (in u.usa.nm.1). Since the NM map was not changed recently and that CA map arrived last night, I concluded that it was a problem with bcsinc. Sure enough, commenting the bcsinc entry out of the CA map solved the problem. I had the same problem, noticing it when pathalias was already consuming 23 Megs (!) of core. I didn't bother tracking it down, but picked up the current pathalias from uunet, installed it and the problem went away....
mem@zinn.MV.COM (Mark E. Mallett) (06/01/90)
In article <1990May29.182555.27806@pmsmam.uucp> wwm@pmsmam.uucp (Bill Meahan) writes: >Since the latest distribution I've received from comp.mail.maps, my attempts >to build a new pathalias database result in pathalias hanging forever while >taking up about 4.5 MEGS of core. Hmm, I just commented on this in comp.unix.i386, as follows (the additional light shed here is that I can reproduce the problem with a 3-line input file): ---------- In article <RON.90May30172314@mlfarm.uucp> ron@mlfarm.uucp (Ronald Florence) writes: >We use pathalias (9.1 87/10/04) with Xenix 2.3.2, on a ps2/80 with six >megabytes of ram. Building our map normally takes ~2 minutes. > >The recent batch of maps apparently has taken our pathalias over some >threshold. Without the map u.usa.ca.1, the build takes the same ~2 >minutes. With all of the maps included on the command line, pathalias >churns and swaps, slowly growing in size. An hour later, when I >finally killed the process, it was at 5704K (according to ps); etc. I spent quite a bit of yesterday tracking this down. The problem seems to be that bcsinc (in u.usa.ca.1) and rt1 (in u.usa.nm.1) declare each other to be terminal links with DEAD cost. I was able to replicate the problem with a 3-line pathalias input file: bcsinc <rt1>(DEAD) ditka <rt1>(DEMAND+FAST), zinn(HOURLY+FAST) rt1 <bcsinc>(DEAD) Running pathalias with trace options shows that rt1->bcsinc and bcsinc->rt1 (that is, the terminal defs of them) are trying to be resolved coninuously, with ever-increasing costs and links. I got around it by adding this to my local-defs file (which is a file that I feed into the pathalias run to supply local definitions and overrides): bcsinc rt1(DEAD) rt1 bcsinc(DEAD) In fact, I originally had "bcsinc" spelled wrong in the addition, and it still worked. Apparently all it needs is some other route between the two sites. I checked this three-line problem with a neighbor, who ran it with the -l zinn option (to pretend it was me), and they had the same results -- pathalias went into an infinite loop. Incidentally, I also checked this with another neighbor who does NOT have the problem. He says he is running an "unreleased" version of pathalias 9.1, and in fact the trace output is quite different from mine -- both in the formatting (terminals have <> instead of trailing ') and in the costs for DEAD and back links. I can hardly wait to see the update... -mm- -- Mark E. Mallett Zinn Computer Co/ PO Box 4188/ Manchester NH/ 03103 Bus. Phone: 603 645 5069 Home: 603 424 8129 BIX: mmallett uucp: mem@zinn.MV.COM ( ...{decvax|elrond|harvard}!zinn!mem ) Northern MA and Southern NH consultants: Ask (in mail!) about MV.COM