🚀 go-pugleaf

I have a problem that >seems< to be internals oriented so I will
post it here. I have a program that is linked with several shareable
images (RTLs). This program is submitted to a batch queue nightly.
Every fouth or fifth night the guy suffers an access violation and
produces a trace back dump in the .LOG file produced by the batch 
handler.

This >should< be a simple one. As I understand it, the trace back
shown below indicates that the violation occurred in a routine that
was called from another routine that was called by the main program.
I have seen trace backs from hell where the error occurred far deeper
than this and where images located via FIND_IMAGE_SYMBOL calls were 
involved. This had to be an easy one. Here goes:

	%SYSTEM-F-ACCVIO, access violation, reason mask=00,
        virtual address=00000018, PC=0011037f, PSL=03c00004

	module name   routine name  line       rel PC       abs PC

                                              0011037f     0011037f
                                              00112cd6     00112cd6
        ET_TC_LOGMGR  verify_tape   8538      000000bc     00001d87
        ET_TC_LOGMGR  proc          8434      0000004f     00001a8d
        ET_TC_LOGMGR  main          7922      00000019     00000e19

The image I am running in the field is linked with debug but run with
the /NODEBUG qualifier. I wait for failures and then run it at work
with debug enabled trying to locate the fault. 

I KNOW that at line 8538 in the main image, a call is made to a routine
that resides in a shareable image. I am assuming that the trace back is
telling me that when this routine reached PC 00112cd6, it called another
routine. This second routine committed an access violation when the
PC reached 0011037f.

The problem I have is that the PC addresses for the two routines 
(00112cd6 & 0011037f) appear to be in outer space when I compare them
with the routine address I derive from DEBUG (see below for method. Is it
flawed?). What am I doing wrong?

I can write a test program that causes a shared image routine to fail, get 
the test program in the debugger and acurately fix the point of failure 
as shown below (trace back approximated):

	$run test/nodebug

	%SYSTEM-F-ACCVIO, access violation, reason mask=00,
        virtual address=0000000, PC=00095632, PSL=03c00004

	module name   routine name  line       rel PC       abs PC

                                              00095632     00095632
        ET_TC_LOGMGR  main           82       00000019     00000e19


	$run test
	DBG> set module SHARE$ETRTL
	DBG> ex/ins ETRTL_ROUTINE_THAT_FAILS
	     entry mask ^M<R2>
	DBG> ex/ins
	     JMP        L^SHARE$ETRTL+1a629
	DBG> eval/addr SHARE$ETRTL+1a629
	     95629

As you can see the debugger derived address of the failing shared image
routine (after vector fixup) is 95629. The trace back shows the fault
occurred at 95632. Not far away huh? If I step into the failing shared
image routine with the debugger the first address I see is the address of 
the fixup vector jump instruction. On the very next step, the address
changes to 95629, the debugger derived address of the routine. I can step
through until the error occurs exactly at 95632. Incredible, 'perfect world'
neatness. 

Why don't I have this kind of luck with the big guy? Obviously its a problem
with VMS (;-). Any suggestions on this will be greatly appreciated. This is
running under VMS 5.3. Code (to include the shareable image involved) is
VAX C V2.3. Hardware varies (3100, 6400,...) as does evironment (some
clustered, some not). 



				Barry A. Waters


Net (I think): uunet!cgi!baw	
 Tel (I Know): 404-458-2371