- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks for confirming this.
Patrice.
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page