- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
@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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
If you can reproduce the problem with the version 18 compiler, submit a problem report to Intel through the Online Service Center.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page