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
How does the peak virtual size of the process compare with the PGFLQ of
the process?
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.
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
>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.