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

possible compiler bug: memory leakage with allocatable components

Aldo_H_
Beginner
598 Views

Dear developers,

We've been having difficulty with a memory leaks, and we suspect the problem is in the compiler. The appended code (test_leak.f90) is similar to ours, and reproduces the problem.

After executing the following commands, we see the memory usage of a.out increase approximately linearly in time.

ifort test_leak.f90
a.out &
top

We don't see what what's wrong with the code.

We noted that the program barely uses any memory when the FINAL procedures are uncommented. But shouldn't they be redundant? In "Modern Fortran Explained", Metcalf et al. say that "when a variable of derived type is deallocated, any ultimate allocatable component that
is currently allocated is also deallocated, as if by a deallocate statement".

Extra info:

  • OS: CentOS Linux release 7.3.1611 (Core)
  • ifort version: 17.0.4
  • The command lscpu prints the following CPU info:
    Architecture:          x86_64
    CPU op-mode(s):        32-bit, 64-bit
    Byte Order:            Little Endian
    CPU(s):                12
    On-line CPU(s) list:   0-11
    Thread(s) per core:    1
    Core(s) per socket:    6
    Socket(s):             2
    NUMA node(s):          2
    Vendor ID:             GenuineIntel
    CPU family:            6
    Model:                 62
    Model name:            Intel(R) Xeon(R) CPU E5-2630 v2 @ 2.60GHz
    Stepping:              4
    CPU MHz:               2899.914
    BogoMIPS:              5205.87
    Virtualization:        VT-x
    L1d cache:             32K
    L1i cache:             32K
    L2 cache:              256K
    L3 cache:              15360K
    NUMA node0 CPU(s):     0-5
    NUMA node1 CPU(s):     6-11

 
0 Kudos
6 Replies
FortranFan
Honored Contributor II
598 Views

@Aldo H.,

Your program main has an infinite loop!

    do
        allocate(temp,source=f1 + f2)
        call temp%eval(3.0,value)
        deallocate(temp)
    enddo

Using Intel Fortran compiler 18.0, I don't notice any memory leak issue with a revised test case that executes the DO loop N number of times with N set to 10 once and 100 a second time.  

0 Kudos
Aldo_H_
Beginner
598 Views

I think the program leaks a tiny bit of memory every time it executes `deallocate(temp)` and fails to free allocatable components. It's only a few real numbers, and so you'll need many loops for the problem to become noticeable.

With the following loop, the program takes about a minute on my computer. Memory usage should stay constant in time, but it doesn't.

    do i = 1, huge(i)/100
        allocate(temp,source=f1 + f2)
        call temp%eval(3.0,value)
        deallocate(temp)
    enddo

 

0 Kudos
Steve_Lionel
Honored Contributor III
598 Views

If allocatable components are not deallocated when a variable of that type is deallocated, that's a compiler bug and a test case should be submitted to Intel. You can't necessarily depend on the OS report of memory growth to identify leaks. I've run a few tests with compiler version 18 and don't see any leaks.

0 Kudos
Aldo_H_
Beginner
598 Views

Thank you for you reply. I know my report is possibly compiler/OS/hardware specific. I'm not sure what else I can do to help you reproduce the bug.

I have firmly established that the appended code behaves differently depending on whether the FINAL procedures are included, at least on my computer with ifort 17. Without the FINAL procedures, the code eventually clogs up all available memory and crashes. With the FINAL procedure, it appears it can run indefinitely.

How do I procede?

0 Kudos
Steve_Lionel
Honored Contributor III
598 Views

If you can reproduce the problem with the version 18 compiler, submit a problem report to Intel through the Online Service Center.

0 Kudos
Aldo_H_
Beginner
598 Views

I tried with the ifort version 18.0.1 and my code now works without problems. It seems that this bug was indeed fixed in the newest compiler.

0 Kudos
Reply