Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Fortran 90 virtual memory problem.

49 views
Skip to first unread message

Erik

unread,
Nov 3, 2006, 2:27:41 AM11/3/06
to
One of our programmers is trying to run a Fortran 90 program which
attempts to use more that 1GB of virtual memory. The program crashes
with %SYSTEM-F-ACCVIO. The help text for ACCVIO is clear about
what it means, but he runs the same code on Tru64 UNIX without error.
Have we hit some kind of virtual memory limit, or is it some
fundamental programming error ?
To try and debug this we have produced a test program (see below)
which gives the same error when trying to allocate an array.
The environment is VMS 7.3-2, DS15 Alpha with 4GB memory, Fortran
V7.5, PGFLQUO is 19340340. I recall a 1GB limit with Fortran 77, due to
P0 space limits. Is there some qualifier we should be using with
Fortran 90 to allow us to address more than 1GB of virtual memory?

Thanks for your help.
Erik Ahlefeldt.
----------------- TEST.F90 ---------------------

real(kind=8), allocatable, dimension(:) :: kt !, lt
!DEC$ ATTRIBUTES ADDRESS64 :: kt

do k=121000000,200000000,700000
write(*,*)k
allocate(kt(k),stat=ker)
write(*,*)ker,k
kt=0
deallocate(kt)
enddo
end

--------------- END TEST.F90 ---------------------
$ F90 TEST.F90
$ LINK TEST
$ RUN TEST

%SYSTEM-F-ACCVIO, access violation, reason mask=04, virtual
address=000000002E186010, PC=0000000000030240, PS=
0000001B
%TRACE-F-TRACEBACK, symbolic stack dump follows
image module routine line rel PC abs
PC
A A$MAIN A$MAIN 9 0000000000000240
0000000000030240
0 FFFFFFFF8025FE94
FFFFFFFF8025FE94

Ian Miller

unread,
Nov 3, 2006, 4:22:22 AM11/3/06
to
For that size of virtual memory you should be using P2 region. Do you
know the address of the allocated memory?

How does the peak virtual size of the process compare with the PGFLQ of
the process?

Volker Halle

unread,
Nov 3, 2006, 5:18:35 AM11/3/06
to
Erik,

when running this example on OpenVMS Alpha V8.3 (with PGFLQUOTA=500000
= too low), I get:

$ run test
121000000
41 121000000
%DEBUGBOOT-W-EXQUOTA, process quota exceeded


%SYSTEM-F-ACCVIO, access violation, reason mask=04, virtual

address=000000000000
0000, PC=0000000000030240, PS=0000001B

Setting PGFLQUOTA to the value you've specified, I can get the programm
runing, but my pagefiles are currently not big enough and I don't want
to risk anything...

It should be noted, that the failing PC I'm seeing is the same as
yours. In your case, the failing VA is 2E186010, a high P0 space
adddress.

Volker.

Steve Lionel

unread,
Nov 3, 2006, 1:51:19 PM11/3/06
to
Erik wrote:
> One of our programmers is trying to run a Fortran 90 program which
> attempts to use more that 1GB of virtual memory. The program crashes
> with %SYSTEM-F-ACCVIO. The help text for ACCVIO is clear about
> what it means, but he runs the same code on Tru64 UNIX without error.
> Have we hit some kind of virtual memory limit, or is it some
> fundamental programming error ?

Your program is very, very naughty. It use the STAT= keyword to get
the status of the ALLOCATE but fails to check it before using the
contents of the allocated array.

Either remove the STAT= (so that an error can be signaled) or test the
status value before trying to use the array. You're probably running
into some quota or other limit.

The use of ADDRESS64 causes LIB$GET_VM_64 to be used for the
allocation.

(It's been many years since I worked on this, but I am pretty sure I
still understand how it works.)

Steve

Erik

unread,
Nov 6, 2006, 1:51:05 AM11/6/06
to

Thanks for the replies.

>For that size of virtual memory you should be
>using P2 region.

How do we tell the program use P2 space instead
of P0 space ?

>How does the peak virtual size of the process
>compare with the PGFLQ of the process?

Peak virtual size is 7797248, PGFLQUO is 19340340.

Steve, we know that our use of STAT is naughty,
we just cut down the original program to the barest
minimum code that would cause the error (and not get
optimised out by the compiler) and illustrate the
problem.

0 new messages