Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
Beginner

Defining a finalizer of type with non-allocatable component will lead to memory leak?

Jump to solution
module M_dat
	implicit none
	type t_dat
		integer(8) :: icost(10000)
	contains ! commenting this line and next line fix memory leak problem
		final :: delete_dat,delete_dat_array
	end type
contains
	subroutine delete_dat(self)
		type(t_dat), intent(in) :: self
		write(*,*)"delete"
	end subroutine
	subroutine delete_dat_array(self)
		type(t_dat), intent(in) :: self(:)
		write(*,*)"delete array"
	end subroutine

	recursive subroutine test(step)
		integer :: step
		integer :: i
		type(t_dat) :: p(10)
		if(step==0) return
		do i=1,size(p)
			p(i)%icost=i
		enddo
		step=step-1
		call test(step)
	end subroutine
end module

program main
	use M_dat
	implicit none
	integer :: step
	step=100
	call test(step) ! the larger the step, the more memory will be leaked
	write(*,*)"finished"
	read(*,*)
end program

above program is just an example and in real program type t_dat will contain some pointers that should be deallocated in finalizer. Anyway this program will cause memory leak and I don't understand why.

0 Kudos

Accepted Solutions
Highlighted

You can't go by memory usage

Jump to solution

You can't go by memory usage as this doesn't go back down on deallocation. The deallocated memory is still in the process, available to future allocations.

I ran Intel Inspector XE's memory leak analysis and it found no issues.

Retired 12/31/2016

View solution in original post

0 Kudos
4 Replies
Highlighted

I'm not seeing evidence of a

Jump to solution

I'm not seeing evidence of a memory leak when built with 17.0.1. Which compiler version are you using and why do you think there is a leak?

Retired 12/31/2016
0 Kudos
Highlighted
Beginner

I'm using ifort 16.0.3.210.

Jump to solution

I'm using ifort 16.0.3.210. When the program is run and blocked at the read(*,*) statement, the memory usage is much higher than normal one (the one without user-defined finalizer). Furthermore the memory usage is almost linearly related to "step" variable in the main program.

0 Kudos
Highlighted
1 View

You can't go by memory usage

Jump to solution

You can't go by memory usage as this doesn't go back down on deallocation. The deallocated memory is still in the process, available to future allocations.

I ran Intel Inspector XE's memory leak analysis and it found no issues.

Retired 12/31/2016

View solution in original post

0 Kudos
Highlighted
Beginner

It seem to be the case,

Jump to solution

It seems to be the case, thanks very much!

0 Kudos