forums.silverfrost.com

[dbrauer42]

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+2*i))
buffer(:)=' '
write(6,*) 'press any key to deallocate buffer...'
pause
deallocate(buffer)
end do

end program allocate_test

[PaulLaidler]

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.

[dbrauer42]

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.

[JohnCampbell]

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

[PaulLaidler]

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.

[PaulLaidler]

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.

[dbrauer42]

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

[dbrauer42]

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

[PaulLaidler]

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.

[dbrauer42]

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?

[PaulLaidler]

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.

[JohnCampbell]

Paul,

I will test your suggestion of

[PaulLaidler]

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.