finalization of function return type memory leak ?

[Patrice_l_]

Hi,

I have a memory leak with the return variable of a constructor. If the allocation is made out of the constructor then the component is automatically deallocated after. The following code show the behavior. If the class(*) is replace by an integer there is no memory leak. Of course if i write a final subroutine that deallocate it solves the issue, but then what is the exact rule for automatic finalization for derived type and extended derived type.

Thanks.

module tata
implicit none

type :: b_type
        class(*),allocatable :: b 
        !integer ,allocatable :: b  !  NO LEAK with an integer
end type

        type,extends(b_type) :: intb 
        end type
        interface intb
                module procedure :: intb_constructor
        end interface
contains
function intb_constructor(i) result(a)
        type(intb) :: a
        integer :: i
        allocate(a%b,source=i)
end function        
end module

program foo
use tata
implicit none
type(intb) :: d,d2,c,c2
type(b_type) :: e1,e2
integer :: j
j=1
allocate(e1%b,source=j)
allocate(e2%b,source=j)
        
allocate(d%b,source=j)
allocate(d2%b,source=j)

c=intb(1)
c2=intb(3)

        
end program

==14632== 4 bytes in 1 blocks are definitely lost in loss record 7 of 9
==14632==    at 0x4C29F90: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==14632==    by 0x41C83F: for_allocate (in /home/patrice/Projects/fortran_rbtree/a.out)
==14632==    by 0x40368B: do_alloc_copy (in /home/patrice/Projects/fortran_rbtree/a.out)
==14632==    by 0x40441B: for_alloc_copy (in /home/patrice/Projects/fortran_rbtree/a.out)
==14632==    by 0x402A34: tata_mp_intb_constructor_ (finalbug.f90:17)
==14632==    by 0x402F0E: MAIN__ (finalbug.f90:34)
==14632==    by 0x4027CD: main (in /home/patrice/Projects/fortran_rbtree/a.out)
==14632==
==14632== 4 bytes in 1 blocks are definitely lost in loss record 8 of 9
==14632==    at 0x4C29F90: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==14632==    by 0x41C83F: for_allocate (in /home/patrice/Projects/fortran_rbtree/a.out)
==14632==    by 0x40368B: do_alloc_copy (in /home/patrice/Projects/fortran_rbtree/a.out)
==14632==    by 0x40441B: for_alloc_copy (in /home/patrice/Projects/fortran_rbtree/a.out)
==14632==    by 0x402A34: tata_mp_intb_constructor_ (finalbug.f90:17)
==14632==    by 0x40304D: MAIN__ (finalbug.f90:35)
==14632==    by 0x4027CD: main (in /home/patrice/Projects/fortran_rbtree/a.out)
==14632==
==14632== LEAK SUMMARY:
==14632==    definitely lost: 8 bytes in 2 blocks
==14632==    indirectly lost: 0 bytes in 0 blocks
==14632==      possibly lost: 0 bytes in 0 blocks
==14632==    still reachable: 56 bytes in 7 blocks
==14632==         suppressed: 0 bytes in 0 blocks

[pbkenned1]

I don't see why automatic deallocation should  behave any differently if the allocation was done through the constructor.  It seems to me deallocation should be automatic, regardless of whether the result has an intrinsic allocatable component or an unlimited polymorphic allocatable component.  The fact that there is no memory leak if you do the allocation directly suggests to me that automatic deallocation is the right behavior in either case.

Let me run this by the developers.

Patrick

[pbkenned1]

I was encouraged to report this to the developers, which I have done (internal tracking ID DPD200370808). 

It's clear that deallocation occurs automatically when the allocatable component type is integer:

$ grep dealloc U558626-int-alloc.s
        call      for_dealloc_allocatable                       #36.1 !!! c=intb(1)
        call      for_dealloc_allocatable                       #37.1 !!! c2=intb(3)
$

No such calls are made when the allocatable component type is class(*), thus the memory leak.

Patrick
 

[Patrice_l_]

Thanks for confirming this.

Patrice.