Memory deallocation fails with /check and /undef

Hello,

we need to allocate and deallocate a character field within a do-loop (please see example code below). Using the compiler flags /check or /undef we have discovered that the executable doesn't release the allocated memory but keeps allocating more and more system memory. With /debug or without any debugging flags everything works fine.

We use FTN95 version 5.3.0 and 4.9.1 on WinXP.

Is this behaviour correct? Does anybody know a workaround for this? Any help is very much appreciated.

Regards, Daniel.

Example code:

program allocate_test implicit none

integer, parameter :: bwidth=500 integer :: i,n character(len=bwidth),allocatable,dimension(:) :: buffer

n=10 do i=1,20 write(6,) 'i=',i
if (allocated(buffer)) then deallocate(buffer) end if
write(6,) 'allocating buffer...' pause allocate(buffer(n+2i)) buffer(:)=' ' write(6,) 'press any key to deallocate buffer...' pause deallocate(buffer) end do

end program allocate_test

If you use the salflibc.dll released with version 5.30 of FTN95 then you will probably get a better response if you set the environment variable

FTN95_NEW_MEMORY=TRUE

You can set FTN95_NEW_MEMORY to anything to get the new memory model. Reset it to blank to restore the old model.

Hello Paul,

thank you for the fast reply.

I tried setting FTN95_NEW_MEMORY=TRUE before compilation and execution. There was no change in memory usage.

Any other ideas?

Regards Daniel.

Paul,

Is it a good time to think about how /CHECK and /DEBUG interact with both ALLOOCATE and /3GB. It is my understanding that:-

/CHECK stops the release memory with DEALLOCATE or default de-allocate on exit of the allocating routine. This substantially changes how the program runs.

/DEBUG stops the use of /3gb getting access to more than 2gb of memory, so I can't get a good trace-back if the program crashes.

With these limitations, it is not possible to easily debug how a program is manageing allocated memory, if you have a suspected problem.

I have had to resort to including a reporting subroutine after each allocate or before each deallocate statement. This routine reports :-

1. the name of the variable, as a character string.
2. the start memory address of the allocated array
3. the size of the array (I should use INQUIRE, to calculate the size)
4. the allocate/deallocate operation type

To report the allocation address, I report after the allocate statement, so if the program crashed, I don't get the last ALLOCATE report.

Could this debugging functionality be improved, or have I got the restrictions wrong ?

John

Daniel

When I tested your sample, there was a definite change in the memory usage. Are you experienced with setting environment variables either via a SET command in the DOS box you are using or via the Control Panel?

Basically, under the old model, FTN95 arranges for a large chunk of memory to be allocated at the outset. So when memory is released by the program, this is not obvious in the Task Manager etc.

With the new model you generally get a more immediate external response.

John

You have raised a number of questions and I guess it would take me some time to deal with them all in one go. If I start with one issue you can bring me back to the others later.

When you say that memory is not de-allocated in CHECK mode, do you mean that a de-allocate call does not appear in the explist or just that it is not apparent in an external application that monitors memory usage?

As far as I know, memory is usually deallocated (whether in CHECK or not) but I can look into this if necessary. As I mentioned in my reply to Daniel, this may not be apparent externally.

Paul, I'll check if version 5.30 of the salflib.dll is in use. Daniel.

Paul, I testet my sample on a vm with win2k and no Salford compiler installed. salflibc.dll V5.30 was located in the same directory as the exe (which was compiled before on the winxp host pc). During the 20 loops the task manager of win2k shows a memory usage starting at 2.608kb and increasing to 11.900kb.

Here's the batch file I use to compile and/or run the sample:

set FTN95_NEW_MEMORY=TRUE set

rem compile rem debug mode 'undef' keeps system memory rem ftn95 allocate_test.f90 /list /implicit_none /colour /undef

rem debug mode 'check' keeps system memory rem ftn95 allocate_test.f90 /list /implicit_none /colour /check

rem debug mode 'debug' frees system memory rem ftn95 allocate_test.f90 /list /implicit_none /colour /debug

rem non-debug mode frees system memory rem ftn95 allocate_test.f90 /list /implicit_none /colour

rem link rem slink allocate_test.obj -file:allocate_test.exe

rem run rem sdbg allocate_test.exe allocate_test.exe

set FTN95_NEW_MEMORY=

The 'set' command shows that the environment variable FTN95_NEW_MEMORY is set to TRUE

My apologies.

FTN95_NEW_MEMORY has not been implemented for /check etc.

So the memory is being released internally and hopefully can be reused but this will not be apparent to an external memory monitor.

Ok. This was only a sample to show what the problem is. Our real application is allocating up to 1.106.503kb and then the debugger terminates with an acess violation. Is there any way we can debug it with /undef?

It is possible that you might get more memory by using the 3GB switch in your boot.ini together with /3GB as a SLINK option. This assumes that you are using Windows XP. Not sure what happens with Vista.

You have to force SLINK to use /3GB for CHECK mode etc, since /2GB is the ddefault but you will probably get away with it.

Paul,

I will test your suggestion of

You have to force SLINK to use /3GB for CHECK mode etc, since /2GB is the default but you will probably get away with it. I am having problems with /DEBUG also. I am not sure that I was forcing the use in slink.

I have had recent problems using /check or sdbg to find errors with ALLOCATE, including an unable to allocate an array of about 10 bytes. I did not find out what resource was exhausted. I developed the allocate reporting routine to see what memory was being used but could not find the error, which disappeared when removing /check. My conclusion was there was a significant change to the memory management when /check was installed. All these tests are done on my /3gb settings and FTN95_NEW_MEMORY=ON.

John

By default SLINK uses /3GB for release mode and /2GB for anything else.

I will have to look again at the new memory model in order to see when it comes into play.