%SYSTEM-F-ACCVIO and open procedure (LIBRTL)

[MatjazP]

I have a application written in fortran. Until yesterday it worked fine.
Today I got the following error message:
%SYSTEM-F-ACCVIO, access violation, reason mask=00, virtual address=0000000000001F53, PC=FFFFFFFF808392D4, PS=0000001B
%TRACE-F-TRACEBACK, symbolic stack dump follows
image module routine line rel PC abs PC
LIBRTL 0 000000000000B2D4 FFFFFFFF808392D4
DEC$FORRTL 0 00000000000860F4 FFFFFFFF80CFC0F4
DEC$FORRTL 0 0000000000059688 FFFFFFFF80CCF688
DEC$FORRTL 0 000000000005A6AC FFFFFFFF80CD06AC
DEC$FORRTL 0 000000000005C614 FFFFFFFF80CD2614
MAINT PRICE_MANY PRICE_MANY 862 00000000000007BC 0000000000050B2C
MAINT MAIN MAIN 2458 00000000000003A8 0000000000054AE8
MAINT TAX TAX 1585 0000000000003378 00000000000540B8
MAINT MAINT MAINT 779 00000000000002AC 00000000000502AC
0 FFFFFFFF8037BCE4 FFFFFFFF8037BCE4
%TRACE-I-END, end of TRACE stack dump

The same message occurs every time I want to call open procedure (opening file) after a while (first few (100 or so) works fine, but then i get this message)). Any ideas?

Thanks
MP

[Volker Halle]

MP,

welcome to the OpenVMS ITRC forum.

An access violation is caused, because the LIBRTL code tried to access an invalid address: 00001F53 - this address cannot be read.

The code in LIBRTL is most likely o.k., it's just some parameter being passed to this call, which provides this invalid address.

Do you check the return status in your open-file routine ? Do you close the files again ?

Using $ SET PROC/DUMP, you can force a process dump to be written, if this error occurs. You can then analyze the process dump with ANAL/PROC.

Or you can run your program under debugger control (RUN/DEBUG) and try to trace back the bad parameter value, when the error happens.

Volker.

[Bojan Nemec]

Matjaž,

Dobrodošel na OpenVMS ITRC forumu.
(welcome to the OpenVMS ITRC forum.)

As Volker has already said:

>> Do you close the files again ?

If the message occurs when you open a file, maybe you reached the open file quota. Which is 100 by default. Check the limit in UAF or with SHOW PROCESS/QUOTA. You can also monitor the changes of the quota from another terminal when the program is running repeating SHOW PROCESS/QUOTA/ID=. Where is the process id.

Also check what exactly is doing your program PRICE_MANY at line 862.


Bojan

[John Gillings]

MP,

Without your exact OpenVMS version (or even Architecture!), it's difficult to say for sure, but offset 0B2D4 in LIBRTL on Alpha is probably part of LIB$VM_MALLOC, so best guess is your program is leaking virtual memory and eventually hitting a quota or other limit (a theory which also fits your observation).

Try adding a call to LIB$SHOW_VM just before line 862 in PRICE_MANY. Just:

CALL LIB$SHOW_VM

This will output a summary of VM allocations at the time. Are they growing? As well as open file limits, Fortran also has LUN limits. Make sure you're not exceeding them.

If this doesn't help, please post the statement on line 862, (OPEN statement?) along with the values of any variables used in the statement.