Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.
Announcements
Welcome to the Intel Community. If you get an answer you like, please mark it as an Accepted Solution to help others. Thank you!
For the latest information on Intel’s response to the Log4j/Log4Shell vulnerability, please see Intel-SA-00646
26857 Discussions

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

Zuodong_Y_
Beginner
111 Views
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
1 Solution
Steven_L_Intel1
Employee
111 Views

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.

View solution in original post

4 Replies
Steven_L_Intel1
Employee
111 Views

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?

Zuodong_Y_
Beginner
111 Views

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.

Steven_L_Intel1
Employee
112 Views

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.

View solution in original post

Zuodong_Y_
Beginner
111 Views

It seems to be the case, thanks very much!

Reply