|
forums.silverfrost.com Welcome to the Silverfrost forums
|
View previous topic :: View next topic |
Author |
Message |
DanRRight
Joined: 10 Mar 2008 Posts: 2816 Location: South Pole, Antarctica
|
Posted: Thu Oct 23, 2014 9:33 pm Post subject: Re: |
|
|
DanRRight wrote: | Wilfried, i'd also add the deallocate to your first code |
Sorry I meant Erwin but wrote Wilfried, I'd add deallocate to your code, few large files repeated many times may take huge chunk of RAM making a memory leak |
|
Back to top |
|
|
EKruck
Joined: 09 Jan 2010 Posts: 224 Location: Aalen, Germany
|
Posted: Fri Oct 24, 2014 8:31 am Post subject: |
|
|
Thank Dan,
according to FORTRAN rules local allocated memory has to be de-allocated automatically after return from the subroutine. However, it does not work - I checked it. Memory usage will be increased after each call.
I have to check my other programs as well.
Erwin |
|
Back to top |
|
|
EKruck
Joined: 09 Jan 2010 Posts: 224 Location: Aalen, Germany
|
Posted: Fri Oct 24, 2014 11:03 am Post subject: |
|
|
Paul,
as you see from my last post, size of the occopied memory of my program is increasing after each call of the subroutine. Of course I will deallocate the arrays.
I tried the same when calling the subroutine with the parameters (...,iSizeX,iSizeY) and use automatic allocation like in the code from John Horspool, or as shown below. The occupied memory is still increasing after each call of the subroutine.
Code: |
PROGRAM MemTest1
IMPLICIT NONE
INTEGER*4 I, J, K
DO I= 1, 100000
J = 2000
K = 2000
WRITE(*,'(i10)') I
CALL Sub1 (J, K)
ENDDO
END PROGRAM MemTest1
SUBROUTINE Sub1 (M, N)
IMPLICIT NONE
INTEGER*4 M, N
INTEGER*4 Large(M,N)
Large(1,1) = 123456789
Large(M,N) = Large(1,1)
RETURN
END SUBROUTINE Sub1
|
In the example above everything works fine as well if I use allocate without deallocate.
There seems to be a terrible bug for larger code ?!
Erwin |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7924 Location: Salford, UK
|
Posted: Fri Oct 24, 2014 1:42 pm Post subject: |
|
|
Thanks. I have logged this for investigation. |
|
Back to top |
|
|
EKruck
Joined: 09 Jan 2010 Posts: 224 Location: Aalen, Germany
|
Posted: Sat Oct 25, 2014 12:14 pm Post subject: |
|
|
Paul,
after introduction of an deallocate, the occupied memory of my program is still increasing after each creation of a GIF file.
Therefore I reduced the program to a minimum which I would like to send to you by email for further evaluation (no exe-file).
Erwin |
|
Back to top |
|
|
JohnCampbell
Joined: 16 Feb 2006 Posts: 2554 Location: Sydney
|
Posted: Sat Oct 25, 2014 12:30 pm Post subject: |
|
|
I finally had time to look at what Wilfred posted last Thursday. The following change, using FTN95 Ver 7.10.0 works ok, at least up to exporting the 3 images. I did not look at the BMP import, as I am not familiar with these routines.
As I have demonstrated, export_image@ works well. I think support for .png was introduced recently in Ver 6.35; not sure when .gif was supported.
Hopefully if this example works for you, the difference between .gif and .png shows the limited colour palette. Code: | winapp
program test
implicit none
include <windows.ins>
integer*4 i,j,A
character*1 image(1450000)
character*256 ifile,ofile, gfile,pfile
c_external bmp_imp '__import_bmp'(STRING,REF) : integer*4
c_external gif_exp '__export_gif'(VAL,STRING,REF)
ifile = 'test.bmp'//char(0)
ofile = 'test.gif'//char(0)
gfile = 'test_02.gif'
pfile = 'test_02.png'
! create 24-bits test image
do i = 1,600
A = (i-1)*2400
do j = 1,2400,3
image(A+j ) = char(mod(j,255))
image(A+j+1) = char(mod(i,255))
image(A+j+2) = char(mod(i+j,255))
end do
end do
! off-screen graphics & export to BMP
j = create_graphics_region@(4L,800L,600L)
j = select_graphics_object@(4L)
call display_dib_block@(0,0,image,800L,600L,0,0,800L,600L,0,0,i)
if (i == 0) then
j = export_image@ (ifile)
j = export_image@ (gfile)
j = export_image@ (pfile)
end if
j = delete_graphics_region@(4L)
! import of BMP and export to GIF
A = bmp_imp(ifile,i)
if (i == 0) call gif_exp(A,ofile,i) !! here the program failes
end |
Last edited by JohnCampbell on Sat Oct 25, 2014 1:00 pm; edited 1 time in total |
|
Back to top |
|
|
JohnCampbell
Joined: 16 Feb 2006 Posts: 2554 Location: Sydney
|
Posted: Sat Oct 25, 2014 12:59 pm Post subject: |
|
|
Erwin,
I am trying to understand your memory leak problem. I can't identify which code sample has the problem.
If it relates to reading a .bmp file into a DIB handle, then there is memory associated with the handle, which has to be released.
I have also seen some memory leak associated with some .gif routines, but I recall this was not a large amount of memory.
I think Fortran's use of ALLOCATE is more robust than C's malloc, as the deallocate is now implicitly required.
In the production version of your code, how many .gif files do you need to create ?
John |
|
Back to top |
|
|
DanRRight
Joined: 10 Mar 2008 Posts: 2816 Location: South Pole, Antarctica
|
Posted: Sat Oct 25, 2014 1:26 pm Post subject: |
|
|
If deallocation works by default (or should work) when exit the sub - great, i did not check that lately because having eternal problem with lack of memory i always deallocate. As to how many files - we sometimes output 1000 files for making movies of process dynamics |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7924 Location: Salford, UK
|
Posted: Sat Oct 25, 2014 2:23 pm Post subject: |
|
|
Yes. As I recall, the standard requires an automatic DEALLOCATE on return. |
|
Back to top |
|
|
EKruck
Joined: 09 Jan 2010 Posts: 224 Location: Aalen, Germany
|
Posted: Sun Oct 26, 2014 11:52 am Post subject: |
|
|
Dan, John,
I tried of course to return the memory by setting the DIB handle to zero und calling window_update@. There was no enhancement.
The purpose of the GIF files in this program is to rotate the graphics and make series of GIF files and play it later. For several 3D point cloud objects you can recognize the structure only, when the object will be rotated. Because this is a new feature in the program, I do not know how many shots will be made.
In the other 5 graphics programs - using %gr - the memory is as well increasing but the amount is only 30 to 40 KB per shot and therefore neglectable.
Erwin
BTW: I have sent the source to Paul. |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7924 Location: Salford, UK
|
Posted: Sun Oct 26, 2014 1:21 pm Post subject: |
|
|
Looks like you need
Code: | CALL Release_Screen_Dib@(iBMP_Handle)
|
|
|
Back to top |
|
|
JohnCampbell
Joined: 16 Feb 2006 Posts: 2554 Location: Sydney
|
Posted: Sun Oct 26, 2014 11:38 pm Post subject: |
|
|
I modified the code to produce 100 progressively larger .bmp, .png and .gif images.
It all appears to have worked, until the exit read, which did not work.
It generates about 1,000 mb of graphics files and finishes with little memory usage. I did not use the .bmp import.
At the end, memory usage was 12 mb.
John
Code: | winapp
program test
implicit none
include <windows.ins>
character*1, allocatable, dimension(:,:,:) :: DIB_image
integer*4 n, i,j,k, nx, ny, screen_handle
character*256 ifile, gfile,pfile
do n = 0,99
write (ifile,fmt='(a,i2.2,a)') 'test_',n,'.bmp'
write (gfile,fmt='(a,i2.2,a)') 'test_',n,'.png'
write (pfile,fmt='(a,i2.2,a)') 'test_',n,'.gif'
! create 24-bits test image
nx = 800+n*25 ! increased from 10 to test larger DIB images
ny = 600+n*20 ! was 15
allocate ( DIB_image(3,nx,ny), stat=j )
if ( j /= 0 ) then
write (*,*) 'stop at ALOOCATE for n=',n
stop
end if
do i = 1,ny
do j = 1,nx
k = (j*3-2)
DIB_image(1,j,i) = char(mod(k,255))
DIB_image(2,j,i) = char(mod(i,255))
DIB_image(3,j,i) = char(mod(i+k,255))
end do
end do
! off-screen graphics & export to BMP
screen_handle = 4
j = create_graphics_region@ (screen_handle, nx, ny)
if ( j /= 1 ) then
write (*,*) 'stop at create_graphics_region@ for n=',n
stop
end if
j = select_graphics_object@ (screen_handle)
if ( j /= 1 ) then
write (*,*) 'stop at select_graphics_object@ for n=',n
stop
end if
!
call display_dib_block@ (0,0, & ! the position (X, Y) on the current graphics device
DIB_image,nx,ny, & ! the DIB array
0,0,nx,ny, & ! position on the current graphics device
0,0,j) ! FUNCTION,MODE,ERCODE )
if ( j /= 0 ) then
write (*,*) 'stop at display_dib_block@ for n=',n
stop
end if
!
if (j == 0) then
j = export_image@ (ifile)
if ( j == 0 ) write (*,*) 'unable to create ',trim(ifile)
j = export_image@ (gfile)
if ( j == 0 ) write (*,*) 'unable to create ',trim(gfile)
j = export_image@ (pfile)
if ( j == 0 ) write (*,*) 'unable to create ',trim(pfile)
end if
!
j = delete_graphics_region@ (screen_handle)
deallocate ( DIB_image )
end do
write (*,*) 'test completed; check memory usage'
read (*,*) n
end |
|
|
Back to top |
|
|
DanRRight
Joined: 10 Mar 2008 Posts: 2816 Location: South Pole, Antarctica
|
Posted: Mon Oct 27, 2014 8:43 am Post subject: |
|
|
John,
I think it is not what was needed. Can you make the same creation of graphics files not in main program but **in the subroutine/function** calling it 100 times with and without deallocate inside the subroutine/function? |
|
Back to top |
|
|
EKruck
Joined: 09 Jan 2010 Posts: 224 Location: Aalen, Germany
|
Posted: Mon Oct 27, 2014 10:11 am Post subject: |
|
|
Thank Paul,
using "CALL Release_Screen_Dib@(iBMP_Handle)" the memory is not increasing anymore - as well without deallocate.
Erwin |
|
Back to top |
|
|
EKruck
Joined: 09 Jan 2010 Posts: 224 Location: Aalen, Germany
|
Posted: Fri Nov 07, 2014 11:33 am Post subject: |
|
|
John,
I have implemented your code. It works fine and faster. Thank you as well for your private hint.
I decided to allow users to apply GIF or PNG files. You are right: Using Clearwin+ the PNG files have perfect colors - GIF files are not as good, as well if you have just a few different colors.
The reason is the mode in Clearwin+: Export_Image@ uses with high probability a fixed color palette. When I make a screen copy with Ctrl+Print and create a GIF file in Photoshop, my colors in the file are perfect. Photoshop can use a flexible color palette.
Paul,
change request: Please allow a flexible color palette for GIF files in Export_Image@, because GIF files are for line graphics much smaller then PNG files.
Erwin |
|
Back to top |
|
|
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|