Allocation of memory

A line of code allocating memory generates 'Allocate was unable to obtain sufficient memory'. This seems very odd given that the program has worked nicely for years, I have a 64bit laptop workstation with 16Gb of RAM and 8 i7 cores. The error occurs in either debug or release mode. I need to solve this problem QUICKLY as I am under a lot of pressure to complete simulations, compile a report and attend meetings. The size of the array to be allocated is 1 by 2 by 223 so can hardly be classed as massive!! I appreciate that one can include ISTAT=Ierror in the call to allocate to avoid a crash but the point is that all that does is tell me there is an error. Here is the code segment....and the error occurs with every single call to allocate. When the call occurs NSeg=1, NMAx=223, Nitems=2

[ if(allocated(Bdy_XY))deallocate(Bdy_XY) allocate(Bdy_XY(NSeg_bdy,NMax,Nitems)) ][/code]

The code fragment that you posted is too small to do anything with. Please present a small but complete reproducer, and state the compiler version and compiler options used.

Here is such a code that has the features that you described, yet it can be compiled and run without exhibiting any error using FTN95 8.30.

program georgeX
   implicit none
   double precision, allocatable :: bdy_xy(:,:,:)
   integer :: nseg=1, nmax=223, nitems=2
!
   if(allocated(bdy_xy))deallocate(bdy_xy)
   allocate(bdy_xy(nseg,nmax,nitems))
   bdy_xy(1,1,1)=1.0d0
end program

Thanks for your reply - indeed I agree and have essentially reproduced your code segment and of course it works. The issue is that the same code segment does NOT work in the context of the overall application that I have built which contains about 100 routines. It has worked very nicely for 10 years so this must be something to do with the overall context of the application or something to do with the compiler or liner settings perhaps. I have seen on some posts that this could be to do with the size of the 'heap' or perhaps stack size but I have no idea how to reset that. What is also odd is that the same issue has occurred in other programs I have which are much much smaller - perhaps only 6 routines. So I am completely baffled as to what is going on. ANY help would be appreciated. I have Plato 4.75 and FTN version 8.1

Three thoughts:

1. What changes were made between the time when things were working and when errors started? Did you switch to a different compiler version, use different compiler options, install a new salflibc DLL, or did you make changes to your source code?

2. Can you use the more recent 8.30 (or 8.40, if you are a paying customer) compiler release?

3. Is is feasible to compile with, say, Gfortran?

Are you using 32-bit with /check ? This could explain the problem, if the allocate is used many times. If so, try changing to /debug and see if the problem disappears.

No changes to the compiler were made, no changes to the options and no new Salflibc.dll. Yes I did make a minor change to the source code - added a routine of about 20 lines to write out some data which compiles without errors or warnings and links in fine. I have updated to V8.3. I have tried various different settings for the compiler (/debug etc....) and none of this has made the slightest difference. On the off chance I have also run a complete virus check of the computer and nothing was found. Perhaps I am grasping at straws now but I am desperate to get this going again. I have a 64 bit machine but you say 'Are yo using 32 bit with /check////' I realise that 32 bit and 64 bit address space is very different but was under the impression that the Salford compiler would operate with 64 bit machines OK. Is there a setting I have to activate for this recognition to take place???? I am not aware of such if it exists. it is extremely frustrating - I have used FTN95 for decades without this kind of issue - it has only appeared very recently.

No changes to the compiler were made, no changes to the options and no new Salflibc.dll. Yes I did make a minor change to the source code - added a routine of about 20 lines to write out some data which compiles without errors or warnings and links in fine. I have updated to V8.3. I have tried various different settings for the compiler (/debug etc....) and none of this has made the slightest difference. On the off chance I have also run a complete virus check of the computer and nothing was found. Perhaps I am grasping at straws now but I am desperate to get this going again. I have a 64 bit machine but you say 'Are yo using 32 bit with /check////' I realise that 32 bit and 64 bit address space is very different but was under the impression that the Salford compiler would operate with 64 bit machines OK. Is there a setting I have to activate for this recognition to take place???? I am not aware of such if it exists. it is extremely frustrating - I have used FTN95 for decades without this kind of issue - it has only appeared very recently.

No changes to the compiler were made, no changes to the options and no new Salflibc.dll. Yes I did make a minor change to the source code - added a routine of about 20 lines to write out some data which compiles without errors or warnings and links in fine. I have updated to V8.3. I have tried various different settings for the compiler (/debug etc....) and none of this has made the slightest difference. On the off chance I have also run a complete virus check of the computer and nothing was found. Perhaps I am grasping at straws now but I am desperate to get this going again. I have a 64 bit machine but you say 'Are yo using 32 bit with /check////' I realise that 32 bit and 64 bit address space is very different but was under the impression that the Salford compiler would operate with 64 bit machines OK. Is there a setting I have to activate for this recognition to take place???? I am not aware of such if it exists. it is extremely frustrating - I have used FTN95 for decades without this kind of issue - it has only appeared very recently.

If the source code is not enormous, and you are willing and able to share it, zip up all the source files, data files, if any, and instructions to build, if needed, upload to Dropbox, Onedrive or Google drive, enable public-access, and share the link to the file with us. No promises, but one of us may take it for a spin.

Re: 32-bit or 64-bit.

FTN95 V8.0 and up can target IA32 or X64. If you did not explicitly specify /64 at the command line or select 64-bit target in the Plato IDE, you are producing 32-bit EXEs, regardless of whether your PC has a 32-bit or 64-bit CPU, and regardless of whether your Windows is a 32-bit or a 64-bit version.

The GUI part of the system is built with Winteracter. I have tried putting in /64 in the compiler directive which works fine for routines which do not require access to the Winteracter library, however, anything that state use Winteracter now throws up another error message saying 'Cannot find definition for module Winteracter' though it does find that module if I leave out the /64 switch. I don't understand that as I would not expect the environment variable which is used to point to the Winteracter module to change. It has nothing to do with FT95's folders. Also having read more of the info on 64 I note that the linker switches need to be altered but cannot find in the Winteracter IDE how to do that. So I will chase this lot up first and see if that sort the problem out. bearing in mind that I am using Winteracter I guess it is not going to be feasible for you to test the code very easily. thanks for your input and patience....mine is getting very low!!

Unless you have both the 32 and 64 bit versions of the Winteracter library, you will have to restrict yourself to 32-bit compilations. You cannot mix 32-bit and 64-bit objects, libraries and DLLs -- all the files that are linked must be the same type (i.e., w.r.t. target, IA32 or X64).

If the allocation error occurs prior to any call to the Winteracter routines, one can hunt for the bug even without having Winteracter.

I have an old, Lite version of Winteracter that came with the Lahey compiler, but it will probably not work with FTN95.

George,

FTN95.exe is a 32-bit program that can be used to generate either 32-bit .exe or 64-bit .exe

64-bit .exe can only be run on a Windows 64-bit operating system. If you run Task Manager, you can see what programs/processes that are running are either 32-bit (*32) or 64-bit.

To generate a 64-bit .exe, then all the .obj and .dll files you link must be for a 64-bit .exe, including the 3rd party .dll's you use. As mecej4 indicated, it is unlikely you have 64-bit .dll's for your GUI libraries. Managing the appropriate 32 vs 64 .dll's can be a complex issue. In most cases the 'linker' manages default locations for compiler related .dll's, while using other dll's must be carefully selected.