Access violation in pathalias solved?
fri...@flying-disk.com
pathalias aborting with an access violation (see example at
the end of this note). Since then I have tried a variety
of "fixes", but none of them worked. Finally, I tried
defining the logical name UUCP_MAKEPATHS to "/INLINE" and
it fixed the problem! No more access violations. I
still can't figure out why this fixed the problem and would
appreciate a note from anyone who knows.
The failure would occur about 30 minutes into the job (on
a microVAX-II) and no output files were produced, other than
pathalias.log which was always zero blocks. The few times
I compared the stack and register dumps, they were identical.
-- Alan E. Frisbie Fri...@Flying-Disk.Com
-- Flying Disk Systems, Inc.
-- 4759 Round Top Drive (213) 256-2575 (voice)
-- Los Angeles, CA 90065 (213) 258-3585 (FAX)
-------------------- Start included text --------------------
$!
$! Generate routing data for this host
$!
$ pathalias -fi -l FLYING UUCP_PATH_DATA:d.* UUCP_PATH_DATA:u.*
%SYSTEM-F-ACCVIO, access violation, reason mask=00, virtual address=00000000,
PC=00000000, PSL=03C00000
Improperly handled condition, image exit forced.
Signal arguments Stack contents
Number = 00000005 000480E0
Name = 0000000C 00000000
00000000 7FE73AE4
00000000 00000000
00000000 2FFC0000
03C00000 7FE73B28
7FE73B04
00000D50
00000200
00000328
Register dump
R0 = FFFFFFFF R1 = 0000001E R2 = 00000001 R3 = 00000377
R4 = 00000000 R5 = 7FE73D48 R6 = 00000001 R7 = 00000000
R8 = 7FE7418C R9 = 00044F1C R10= 00000004 R11= 0005A6D0
AP = 7FE73A54 FP = 7FE73A14 SP = 7FE73A90 PC = 00000000
PSL= 03C00000
-------------------- End included text --------------------
fri...@flying-disk.com
fri...@flying-disk.com writes:
> About six months ago, I posted a note about a problem with
> pathalias aborting with an access violation
> Finally, I tried
> defining the logical name UUCP_MAKEPATHS to "/INLINE" and
> it fixed the problem! No more access violations. I
> still can't figure out why this fixed the problem and would
> appreciate a note from anyone who knows.
I got exactly one reply via e-mail about this problem from
Dean Nedelman (nede...@pasadena-dc.bofa.com). He found the
bug and the real fix! I have already passed it on to Jamie and
Mark for inclusion in the next release. Here is Dean's
note so you can fix your own copy:
= I had similar problems here and finally was able to trace down
= the problem (even though I got NO responses from the net :-( ).
= My problem started out by saying 'too many terminal links'. I
= changed (in DEF.H) the definition of n_tloc from short to long,
= and my problems fixed themselves.
Terry Kennedy, Operations Mgr.
> I got exactly one reply via e-mail about this problem from
> Dean Nedelman (nede...@pasadena-dc.bofa.com). He found the
> bug and the real fix! I have already passed it on to Jamie and
> Mark for inclusion in the next release. Here is Dean's
> note so you can fix your own copy:
Note that the pathalias shipped with DECUS UUCP V2.0 is a few releases
behind the latest Unix pathalias. I discovered this when I was generating
my DECUS UUCP paths file on a Unix system for speed and getting different
results than I got on the VAX. Porting the pathalias from DECUS UUCP back
to Unix gave me the same results as on the VAX.
It's hard to say whether DECUS UUCP's pathalias generates "wrong" paths,
but they're certainly different from the ones generated by Unix systems.
The most common difference is when a pair of map entries don't list each
other as neighbors (for example, A lists B but B doesn't list A). There
were also some differences in the tie-beaking.
Terry Kennedy Operations Manager, Academic Computing
te...@spcvxa.bitnet St. Peter's College, Jersey City, NJ USA
te...@spcvxa.spc.edu +1 201 915 9381