Memmory leak with -heap-arrays?

[jtegedor]

Dear Intel Support,

we have run into strange allocation problem using ifort 11.0 under Linux:

jtegedor@dgnl1:/home/jtegedor> uname -a
Linux dgnl1 2.6.5-7.244-smp #1 SMP Mon Dec 12 18:32:25 UTC 2005 x86_64 x86_64 x86_64 GNU/Linux

We are using the -heap-arrays to compile out program due to the problems with the temporary arrays being allocated in the stack. The program attached allocates a matrix and an array, fills them with values, and deallocates them. The process is repeated continuosly. If the array is declared as:

LOGICAL, POINTER, DIMENSION(:) :: l1

Then the memmory usage of the program will grow continuosly until it will use all the memmory available, namely, a memory leak. However if the array is declared as:

LOGICAL, ALLOCATABLE, DIMENSION(:) :: l1

the program runs as expected and it will allocate and deallocate the matrixes keeping the maximum level of memmory used constant, as expected.

Interesting enough is that, if the -heap-arrays 4096 option is NOT used for compilation, both declaration of the array will work without generating a memmory leak. The combination of the -heap-arrays and declaring the array as pointer makes the problem appear.

It was quite tricky to understand the reason for this memory problem, which hopefully we managed to reproduce in a controlled way in the program attached. We would highly appreciate if you could try to reproduce it and let us know how this can be avoided.
Many thanks in advance and best regards,
Javier Tegedor

[Steven_L_Intel1]

If you can provide us a source that demonstrates the problem, we'd be glad to investigate. See below for attachment instructions.

[jtegedor]

Sorry, something went wrong with the attachment, it should be fine now.
Javier

Quoting - Steve Lionel (Intel)

If you can provide us a source that demonstrates the problem, we'd be glad to investigate. See below for attachment instructions.

[Steven_L_Intel1]

Thanks. The issue is related to the WHERE construct. When ll is a POINTER, the compiler is pessimistic about overlaps and it generates a temporary for the assignment. Unfoirtunately, it fails to deallocate it afterward. With an ALLOCATABLE, the compiler knows that there can't be any overlap or discontiguity and doesn't need the temp.

I vaguely remember a similar issue in the past - I will look to see if this is a known problem and if not will escalate it.

[Steven_L_Intel1]

I thought this sounded familiar - I investigated a similar issue in January. It has not yet been fixed by the developers. The issue ID is DPD200111734

[Steven_L_Intel1]

This issue was fixed in 11.1.