|
forums.silverfrost.com Welcome to the Silverfrost forums
|
View previous topic :: View next topic |
Author |
Message |
JohnCampbell
Joined: 16 Feb 2006 Posts: 2585 Location: Sydney
|
Posted: Tue Apr 21, 2015 6:42 am Post subject: Problem with ALLOCATE and /check |
|
|
I am struggling with use of ALLOCATE with /check and this error is stumping me.
I have done a lot of software development lately, using ALLOCATE, to make the program more flexible for problem size and memory size.
I have returned to an old program and am trying to check code, so selectively compile some routines with /check, mainly for argument and bounds checking.
The following snippet of code uses /check, while most libaray routines use /opt, /debug or no option
Code: | INTEGER*4 MULC, MUM_FEM, L3, L4, L5, L6, L7, Le, P_end, stat
!
real*8, allocatable, dimension(:,:) :: EPROP
real*8, allocatable, dimension(:,:) :: COPROP
!
! read and save beam element info
!
call check_allocate ( 'at entry to BEAM' )
!
IF (NUM_MAT <= 0) NUM_MAT = 1
Le = (L6+15*NUME)*4 + (L3+L4+L5+L7+NUME)*8
call allocate_report (le)
stat = 0
!
call check_allocate ( 'about to allocate EPROP' )
!
ALLOCATE ( EPROP(4,NUM_MAT), stat=stat ) ; call alloc_test (stat, 'EPROP(4,NUM_MAT)', 4,NUM_MAT)
|
The resulting report is: Code: | Checking if ALLOCATE is working at entry to BEAM
Allocate target = 0.989 mb
Check of ALLOCATE completed
Allocate target = 0.010 mb
Checking if ALLOCATE is working about to allocate EPROP
Allocate target = 0.989 mb
Check of ALLOCATE completed
Error allocating EPROP(4,NUM_MAT) : stat = 1
dimensions are 4 1
|
My called library routines are:
Code: | subroutine alloc_test (stat, array, n1,n2)
integer*4 stat, n1,n2
character *(*) array
!
if ( stat == 0) return
write (*,*) 'Error allocating ',array,' : stat =',stat
write (*,*) 'dimensions are',n1,n2
stop
end subroutine alloc_test
subroutine check_allocate (from)
!
! This routine allocates a 1mb array to check that ALLOCATE works
!
character from*(*)
integer*4 :: n = 360
real*8, allocatable, dimension(:,:) :: EPROP
real*8, allocatable, dimension(:,:) :: aa
integer*4 stat, le, num_mat
!
write (*,*) 'Checking if ALLOCATE is working ', from
NUM_MAT = 1
Le = (n*n + 4*NUM_MAT)*8
call allocate_report (le)
!
ALLOCATE ( EPROP(4,NUM_MAT), stat=stat ) ; call alloc_test (stat, 'EPROP(4,NUM_MAT)', 4,NUM_MAT)
ALLOCATE ( aa(n,n), stat=stat ) ; call alloc_test (stat, 'aa(n,n)', n,n)
!
DEALLOCATE ( aa )
DEALLOCATE ( EPROP )
write (*,*) 'Check of ALLOCATE completed'
!
end subroutine check_allocate
|
The program is failing trying to allocate an array of 32 bytes, when use of ALLOCATE outside the routine compiled with /check are ok.
Is this a known problem ?
I am using FTN95/Win32 Ver. 7.10.0
John |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 8017 Location: Salford, UK
|
Posted: Tue Apr 21, 2015 7:37 am Post subject: |
|
|
I don't know of any problem in this area.
ALLOCATE calls GlobalAlloc except when /CHECK is applied. Otherwise FTN95/salflibc.dll uses its own storage block for all ALLOCATEs and this storage block is created by calling VirltualAlloc.
Does the code that you have posted demonstrate an error that I can reproduce? |
|
Back to top |
|
|
JohnCampbell
Joined: 16 Feb 2006 Posts: 2585 Location: Sydney
|
Posted: Tue Apr 21, 2015 7:52 am Post subject: |
|
|
I have made a small test which reproduces the result.
Subroutine beam is compiled with /check
Allocate works outside call to routine compiled with /check, or to a routine called from beam, but ALLOCATE does now work in the BEAM subroutine.
The following is a small test example:
https://www.dropbox.com/s/xnawf5zvm59nmtu/Alloc_Test.zip?dl=0
this example uses a large common, but I am surprised by the difference outcome, depending on where "ALLOCATE" is being called from.
do_test.bat is the test batch file
ftn95.tce is my result of the run ( oops! do_test will overwrite this file )
32 bytes is an annoyingly small array to fail on !
John |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 8017 Location: Salford, UK
|
Posted: Tue Apr 21, 2015 11:58 am Post subject: |
|
|
I have downloaded the archive and logged this for investigation.
In the mean time is it possible to do the ALLOCATE in a separate subroutine that does not have /CHECK? applied. Then you will be getting the memory directly via GlobalAlloc.
Another possibility is to use GET_STORAGE@ instead of ALLOCATE because GET_STORAGE@ looks like it will call GlobalAlloc even when /CHECK is applied. |
|
Back to top |
|
|
JohnCampbell
Joined: 16 Feb 2006 Posts: 2585 Location: Sydney
|
Posted: Tue Apr 21, 2015 1:10 pm Post subject: |
|
|
Paul,
Thanks for looking at this. At present, FTN95 does not allow an allocatable array to be allocated in another routine, unless the array is in a module.
I think it may be easier to change the way I am using /check than move these arrays to global allocatable arrays. This has many other implications in the program's development.
It is good to know the reason for the error.
John |
|
Back to top |
|
|
mecej4
Joined: 31 Oct 2006 Posts: 1896
|
Posted: Tue Apr 21, 2015 2:54 pm Post subject: |
|
|
John, using allocatable arrays as arguments to subprograms was not a feature that was provided in Fortran 95. This feature was defined in a technical report (TR-15581) from the ISO committee and became part of Fortran 2003, although some compiler vendors implemented TR-15581 in their Fortran 95 compilers. See http://forums.silverfrost.com/viewtopic.php?t=2951 .
Adding this capability would greatly enhance the usefulness of FTN95, since many codes use this feature of the language. For example, the package Galahad-2 uses it.
Update, 22 July 2015: The output from your example does not contain "Error allocating EPROP(4,NUM_MAT)" when one uses FTN95 7.20. |
|
Back to top |
|
|
JohnCampbell
Joined: 16 Feb 2006 Posts: 2585 Location: Sydney
|
Posted: Thu Jul 23, 2015 1:44 am Post subject: |
|
|
mecej4,
I have today downloaded the test from dropbox and it now runs on Ver 7.10.0
I also found the original .exe on disk and it now runs without error. Back in April, it failed on every run.
Previously the error did not occur on every run of the bigger program, so I may give it another go.
I am not sure what this shows !!
Dan, this is not a huge program (40k lines, 500 routines), but it does use large arrays.
The only change has been the regular Microsoft updates to Win 7.
I should install FTN95 Ver 7.2.
Updates are not going well at the moment ! I've recently installed 2 versions of gFortran 5.1.0, both of which do not work.
John |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 8017 Location: Salford, UK
|
Posted: Thu Jul 23, 2015 6:59 am Post subject: |
|
|
John
If it helps, I think that I could add a new item to /INHIBIT_CHECK.
The extra item would disable the checking code around an ALLOCATE statement. |
|
Back to top |
|
|
JohnCampbell
Joined: 16 Feb 2006 Posts: 2585 Location: Sydney
|
Posted: Thu Jul 23, 2015 9:03 am Post subject: |
|
|
Paul,
Thanks for the offer.
Based on recent posts, it would be good to have ALLOC in the option name; such as /INHIBIT_ALLOC_CHECK.
You posted earlier Quote: | ALLOCATE calls GlobalAlloc except when /CHECK is applied. Otherwise FTN95/salflibc.dll uses its own storage block for all ALLOCATEs and this storage block is created by calling VirltualAlloc. |
Based on this I thought if ALLOCATE could use GlobalAlloc when /CHECK is applied, this may remove the problem. Is this a possible approach ?
/GLOBAL_ALLOC could be a possible option, if it does not cause problems for SDBG.
The main reason I try to use /check is to check the argument lists and then subscripts in range.
Given I can't reproduce the error today, I wonder what is causing the problem.
As a supplementary question: For a multi-dimension array, does /check check each subscript is in range, or only if the memory address is within the array memory limits. ie
real*8 A(3,3)
I = 7
J = 1
aa = A(I,J)
Would this be out of bounds or as it is effectively A(1,3) be ok ?
I find my more common error is when I or J = 0
John |
|
Back to top |
|
|
mecej4
Joined: 31 Oct 2006 Posts: 1896
|
Posted: Thu Jul 23, 2015 12:13 pm Post subject: Re: |
|
|
JohnCampbell wrote: | mecej4,
Updates are not going well at the moment ! I've recently installed 2 versions of gFortran 5.1.0, both of which do not work.
|
For production work you should be using 4.9 or lower. Anything higher is "experimental" -- useful for trying out new language features that do not exist in the "stable" version, but likely to be buggy, as you found. |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 8017 Location: Salford, UK
|
Posted: Thu Jul 23, 2015 3:01 pm Post subject: |
|
|
John
I would use /INHIBIT_CHECK <value> initially because it would be experimental and may not do the trick. |
|
Back to top |
|
|
JohnCampbell
Joined: 16 Feb 2006 Posts: 2585 Location: Sydney
|
Posted: Sat Jul 25, 2015 4:14 am Post subject: |
|
|
Paul,
Thanks for the offer. Can you provide a beta test and I will see what happens ?
The direct failure I am getting is that ALLOCATE appears to run out of available memory. (Which is not being released by DEALLOCATE when /CHECK is used ?)
John |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 8017 Location: Salford, UK
|
Posted: Tue Jun 07, 2016 8:46 am Post subject: |
|
|
John
Sorry for the delay but, now that I look into implementing your request, it seems like the facility that you need is already available.
Please try using /CHECK with /INHIBIT_CHECK 4 to see if this gives the desired behaviour. |
|
Back to top |
|
|
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|