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

Memory leak while using allocatable components

tplaakso
Beginner
409 Views
Hi,

I am having memory deallocation problems, encapsulated in the following piece of code. The idea is to choose either "option 1" or "option 2" and comment out the unwanted lines.
[plain]PROGRAM leak

  TYPE vector

     INTEGER                         :: n = 0
     REAL, DIMENSION(:), ALLOCATABLE :: e

  END TYPE vector

  INTEGER                    :: i, j
  INTEGER, PARAMETER         :: N = 1e6
  TYPE(vector), DIMENSION(3) :: x

  x = vector(3, [1.0, 1.0, 1.0])

  DO i = 1, N

     ! option 1:
     DO j = 1, 3
        x(j) = scalar_times_vector(1.0, x(j))
     END DO
     
     ! option 2:
     x = scalar_times_vector_array(1.0, x)

  END DO

  PAUSE


CONTAINS


  FUNCTION scalar_times_vector(k, x) RESULT

    REAL, INTENT(in)         :: k
    TYPE(vector), INTENT(in) :: x

    TYPE(vector) :: r

    r%n = x%n
    ALLOCATE(r%e(r%n))
    r%e = k * x%e

  END FUNCTION scalar_times_vector


  FUNCTION scalar_times_vector_array(k, x) RESULT

    REAL, INTENT(in)                       :: k
    TYPE(vector), DIMENSION(:), INTENT(in) :: x

    TYPE(vector), DIMENSION(:), ALLOCATABLE :: r

    INTEGER :: i

    ALLOCATE(r(SIZE(x)))
    DO i = 1, SIZE(x)
       r(i)%n = x(i)%n
       ALLOCATE(r(i)%e(r(i)%n))
       r(i)%e = k * x(i)%e
    END DO

  END FUNCTION scalar_times_vector_array

END PROGRAM leak
[/plain]
Choosing "option 1" and compiling with "ifort -free -check -o leak leak.f", results in a memory footprint of approximately 900kB (RSIZE column in top-command). Choosing "option 2" consumes about 94MB of memory. Am I wrong to assume that "option 2" would not result in such a massive memory leak, if the compiler/system call did a proper job of deallocating temporaries from function evaluations? (the allocatable components should be deallocated recursively, right?) I am using version 10.1.006, and trying the latest 11.0.059 revealed that the situation is slightly improved: "option 2" shows now 47MB. Is this a bug/feature in the compiler, OSX, or in me?

regards,
Teemu Laakso
0 Kudos
2 Replies
tplaakso
Beginner
409 Views
For those who might be interested; if I put the array of vectors into another derived type, defined as:
[cpp]  TYPE vector_array

     INTEGER                                 :: n = 0
     TYPE(vector), DIMENSION(:), ALLOCATABLE :: x

  END TYPE vector_array
[/cpp]
and write the corresponding function of scalar multiplication for this type, there is no memory leak. Therefore, the recursive deallocation works, but not for the combination presented in my previous post.

0 Kudos
Kevin_D_Intel
Employee
409 Views

It appears "option 2" exposes a memory leak. It is not unique to Mac OS X. I believe this is similar to another issue I worked recently. I reported your instance to Development and will keep the thread updated as I learn more. Thank you for the nice reproducing test case. (Internal tracking id: DPD200119940)
0 Kudos
Reply