View previous topic :: View next topic |
Author |
Message |
aebolzan
Joined: 06 Jul 2007 Posts: 229 Location: La Plata, Argentina
|
Posted: Fri Nov 04, 2016 5:41 pm Post subject: Error: ALLOCATE was unable to obtain sufficient storage |
|
|
I would like to know what really means this error, because I get it from a program that was running fine....till now.....I do not see where the problem is, because the allocation I am trying to do is just for 200 data points!...I am driving nuts!. I have an old release version of the program that runs fine: if I recompile the same code but now with debbuger, the program crashes with that message.
Agustin |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7925 Location: Salford, UK
|
Posted: Sat Nov 05, 2016 8:21 am Post subject: |
|
|
Agustin
Could you provide more information please.
1. 32 bit or 64 bit?
2. /check, /undef used?
3. "stat=" used or exception raised?
4. Provide the line of code and context that causes the failure |
|
Back to top |
|
|
JohnCampbell
Joined: 16 Feb 2006 Posts: 2554 Location: Sydney
|
Posted: Sat Nov 05, 2016 10:18 am Post subject: |
|
|
Old versions of FTN95 /32 with /check did not appear to release memory to the available pool when DEALLOCATE was selected, or the memory pool was less, or not using the heap. ( I can't remember if this was a problem with /debug also or with SDBG)
I think that this problem has been fixed with more recent versions (not sure which ver no) or will be with /64 /check.
My work around was to test release code or minimise the use /check in routines that repeatedly used ALLOCATE. I used more primitive approaches of writing debug code to test the allocated arrays and report their size, while using release code ( no option or /opt ) All these problems disappeared with /64, although I have not gone back to test /check problems.
John |
|
Back to top |
|
|
aebolzan
Joined: 06 Jul 2007 Posts: 229 Location: La Plata, Argentina
|
Posted: Mon Nov 07, 2016 9:15 pm Post subject: |
|
|
Sorry for the belated answer, but I was out during the last weekend. Apparently the problem is when using /CHECK and under Windows 8. With Windows 10 the program runs fine. Release+/CHECK fails (WIn8 only), Release without /CHECK runs fine (both Win8 and 10). The code is very simple
Code: | external count_lines
ndata = count_lines (filename)
! write (*,*) ndata,' lines identified'
!
if (allocated(data_point)) deallocate(data_point)
allocate(data_point(ndata)) |
seems that the problem is win8.......WIN32 application by the way...
Agustin |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7925 Location: Salford, UK
|
Posted: Tue Nov 08, 2016 8:20 am Post subject: |
|
|
Agustin
I don't know why this is failing but perhaps the simplest fix is to switch off /check for this part of the code. You could, for example, move this to a separate routine in a separate file and switch off /check for that file.
Win32 with /check does reduce the amount of memory available to ALLOCATE but there is no obvious reason (to me) why there should be a difference between Windows 8 and Windows 10.
As a general rule, /check is designed for testing and development only, so /check would normally be switched off when releasing software to customers. |
|
Back to top |
|
|
|