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".
The command lscpu prints the following CPU info:
CPU op-mode(s): 32-bit, 64-bit
Byte Order: Little Endian
On-line CPU(s) list: 0-11
Thread(s) per core: 1
Core(s) per socket: 6
NUMA node(s): 2
Vendor ID: GenuineIntel
CPU family: 6
Model name: Intel(R) Xeon(R) CPU E5-2630 v2 @ 2.60GHz
CPU MHz: 2899.914
L1d cache: 32K
L1i cache: 32K
L2 cache: 256K
L3 cache: 15360K
NUMA node0 CPU(s): 0-5
NUMA node1 CPU(s): 6-11
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.
I think the program leaks a tiny bit of memory every time it executes `
(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
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.
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?