Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.

memory leak of function returning polymorphic allocatable with allocatable components

Emil_S_
Beginner
496 Views

The following code results in a memory leak when compiled with ifort 14.0.3

module testmod

  type :: obj
     integer, allocatable :: i
   contains
     procedure :: add => obj_add
     procedure :: copy => obj_copy
     generic :: operator(+) => add
  end type obj

contains
  subroutine obj_copy(this, source)
    implicit none
    class(obj) :: this
    class(obj) :: source

    this%i=source%i
  end subroutine obj_copy

  function obj_add(A, B) result(C)
    implicit none
    class(obj), intent(in) :: A, B
    class(obj), allocatable :: C

    allocate(C)
    allocate(C%i)
    C%i=A%i+B%i
  end function obj_add
end module testmod

program leak
  use testmod
  implicit none
  class(obj), allocatable :: A, B, C

  allocate(A, B, C)
  A%i=1
  B%i=2
  call C%copy(A+B)
  deallocate(A, B, C)
end program leak

When compiled with

ifort -g -o leak leak.f90 -assume realloc_lhs

Valgrind reports

==21260== 4 bytes in 1 blocks are definitely lost in loss record 1 of 2
==21260==    at 0x4C2B3F8: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==21260==    by 0x419BF8: for_alloc_allocatable (in /mnt/data/PhD/Fortran/bugs/operator-leak/leak)
==21260==    by 0x402F41: testmod_mp_obj_add_ (leak.f90:26)
==21260==    by 0x403431: MAIN__ (leak.f90:39)
==21260==    by 0x402BC5: main (in /mnt/data/PhD/Fortran/bugs/operator-leak/leak)

 

 think this might also be the cause of the problems encountered in this thread https://software.intel.com/en-us/forums/topic/487142 from some time ago.

If I change the result dummy to 

type(obj) :: C

and skip the allocation stuff in obj_add, then the leak is avoided. However, this also results in losing polymorphism, which is undesirable. If the procedure is made as a subroutine, I lose the ability to use it as an operator. Does anybody have any suggestion to work around this issue?

Best regards

Emil Sørensen

0 Kudos
7 Replies
Kevin_D_Intel
Employee
496 Views

I will investigate this issue Emil and post an update shortly.
 

0 Kudos
Kevin_D_Intel
Employee
496 Views

I reproduced your findings and see the same results for newer compilers and reported this to Development (see internal tracking id below) for further investigation. I will update the post with information about any work around and status as I learn it.

(Internal tracking id: DPD200358323)

0 Kudos
Emil_S_
Beginner
496 Views

Thank you very much Kevin, I appreciate it. This leak has really proven to be a show-stopper for my implementation.

0 Kudos
FortranFan
Honored Contributor II
496 Views

Emil S. wrote:

Thank you very much Kevin, I appreciate it. This leak has really proven to be a show-stopper for my implementation.

Emil,

Would you be interested in running your code example through Intel Inspector for Linux (if you don't have a license, you can check with Intel staff about being getting a free evaluation license to their 2015 BETA version) and see whether it can catch the same memory leak that Valgrind found?  If yes, I'll be interested in learning from your findings.

Thanks,

0 Kudos
Emil_S_
Beginner
496 Views

Hi FortranFan

I am unfamiliar with the Intel Inspector, but I have downloaded an evaluation copy of Intel Inspector XE 2013 and gave it a try. This is what I obtained

$ inspxe-cl -version
Intel(R) Inspector XE 2013 Update 9 (build 328075) Command Line tool
Copyright (C) 2009-2013 Intel Corporation. All rights reserved.
$ inspxe-cl -collect mi3 -knob analyze-stack=false -knob detect-leaks-on-exit=true -knob enable-memory-growth-detection=true -knob enable-on-demand-leak-detection=true -knob remove-duplicates=true -knob still-allocated-memory=true -knob stack-depth=16 -module-filter-mode=include -appdebug=off -- /mnt/data/PhD/Fortran/bugs/operator-leak/leak
  
1 new problem(s) found 
    1 Memory leak problem(s) detected 
$ inspxe-cl -report problems -result-dir r000mi3/
P1: Error: Memory leak
 P1.3: Memory leak: 4 Bytes: New
  /mnt/data/PhD/Fortran/bugs/operator-leak/leak.f90(26): Error X3: Allocation site: Function obj_add: Module /mnt/data/PhD/Fortran/bugs/operator-leak/leak

So as far as I can tell, Intel Inspector finds the same memory leak as Valgrind did.

0 Kudos
FortranFan
Honored Contributor II
496 Views

Emil S. wrote:

...

So as far as I can tell, Intel Inspector finds the same memory leak as Valgrind did.

Thank you very much - greatly appreciate your post.  I'll follow-up on my installation of Intel Inspector and check why I don't get the same response.  By the way, I work mainly on Windows platform (our sole Linux box has been unavailable for a while) and am experiencing similar issues with memory leaks with user-defined operators in Fortran 2003/2008 code.  I've been playing around with Intel Inspector on Windows 2015 Beta since Valgrind is unavailable on Windows; I'm not having much luck with Inspector finding leaks even though Dr. Memory (another tool) says there are leaks.  Hence my request to you to do the checking with Inspector on Linux.

Regards,

0 Kudos
Emil_S_
Beginner
496 Views

No problem FortranFan, glad I could help :)

0 Kudos
Reply