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

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

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

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

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

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.