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

[Zuodong_Y_]

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.

[Steven_L_Intel1]

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_]

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 · Accepted 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.

[Zuodong_Y_]

It seems to be the case, thanks very much!