Memory Leaks with OpenMP Tasks and the Intel Compiler Suite - linux

Question

I am trying to parallelize an algorithm using DAG-Scheduling via OpenMP tasks and there many programs are killed by the Linux kernel due to Out-Of-Memory after a calls to the parallelized code although the allocated memory is only 1% of the servers main memory. But this happens only if I use the Intel Compilers from 2015, 2016 or even the new 2017 edition.
Here is a small example building the same task dependency graph as the algorithm crashing:
PROGRAM OMP_TASK_PROBLEM
IMPLICIT NONE
INTEGER M, N
PARAMETER(M = 256, N=256)
DOUBLE PRECISION X(M,N)
X(1:M,1:N) = 0.0D0
CALL COMPUTE_X(M, N, X, M)
! WRITE(*,*) X (1:M, 1:N)
END PROGRAM
SUBROUTINE COMPUTE_X(M,N, X, LDX)
IMPLICIT NONE
INTEGER M, N, LDX
DOUBLE PRECISION X(LDX, N)
INTEGER K, L, KOLD, LOLD
!$omp parallel default(shared)
!$omp master
L = 1
DO WHILE ( L .LE. N )
K = M
DO WHILE (K .GT. 0)
IF ( K .EQ. M .AND. L .EQ. 1) THEN
!$omp task depend(out:X(K,L)) firstprivate(K,L) default(shared)
X(K,L) = 0
!$omp end task
ELSE IF ( K .EQ. M .AND. L .GT. 1) THEN
!$omp task depend(out:X(K,L)) depend(in:X(K,LOLD)) firstprivate(K,L,LOLD) default(shared)
X(K,L) = 1 + X(K,LOLD)
!$omp end task
ELSE IF ( K .LT. M .AND. L .EQ. 1) THEN
!$omp task depend(out:X(K,L)) depend(in:X(KOLD,L)) firstprivate(K,L,KOLD) default(shared)
X(K,L) = 2 + X(KOLD,L)
!$omp end task
ELSE
!$omp task depend(out:X(K,L)) depend(in:X(KOLD,L),X(K,LOLD)) firstprivate(K,L,KOLD, LOLD) default(shared)
X(K,L) = X(KOLD, L) + X(K,LOLD)
!$omp end task
END IF
KOLD = K
K = K - 1
END DO
LOLD = L
L = L + 1
END DO
!$omp end master
!$omp taskwait
!$omp end parallel
END SUBROUTINE
After compiling it using ifort -qopenmp -g omp_test.f90 and running it via valgrind it reports:
==21071== LEAK SUMMARY:
==21071== definitely lost: 0 bytes in 0 blocks
==21071== indirectly lost: 0 bytes in 0 blocks
==21071== possibly lost: 118,489,088 bytes in 113 blocks
==21071== still reachable: 1,286 bytes in 35 blocks
==21071== suppressed: 0 bytes in 0 blocks
where the --leak-check=full option shows the following details:
==21071== 1,048,576 bytes in 1 blocks are possibly lost in loss record 22 of 26
==21071== at 0x4C29BFD: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==21071== by 0x516A807: bget(kmp_info*, long) (kmp_alloc.c:741)
==21071== by 0x516A52D: ___kmp_fast_allocate (kmp_alloc.c:2012)
==21071== by 0x51CD917: __kmp_task_alloc (kmp_tasking.c:991)
==21071== by 0x51CD886: __kmpc_omp_task_alloc (kmp_tasking.c:1131)
==21071== by 0x4034FA: compute_x_ (omp_task_problem.f90:31)
==21071== by 0x51DBCB2: __kmp_invoke_microtask (in /scratch/software/intel-2016/compilers_and_libraries_2016.3.210/linux/compiler/lib/intel64_lin/libiomp5.so)
==21071== by 0x51AA436: __kmp_invoke_task_func (kmp_runtime.c:7058)
==21071== by 0x51AB60A: __kmp_fork_call (kmp_runtime.c:2397)
==21071== by 0x5184517: __kmpc_fork_call (kmp_csupport.c:339)
==21071== by 0x403353: compute_x_ (omp_task_problem.f90:24)
==21071== by 0x402F4C: MAIN__ (omp_task_problem.f90:10)
==21071==
==21071== 24,117,248 bytes in 23 blocks are possibly lost in loss record 23 of 26
==21071== at 0x4C29BFD: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==21071== by 0x516A807: bget(kmp_info*, long) (kmp_alloc.c:741)
==21071== by 0x516A52D: ___kmp_fast_allocate (kmp_alloc.c:2012)
==21071== by 0x51CB5E0: __kmpc_omp_task_with_deps (kmp_taskdeps.cpp:452)
==21071== by 0x403D54: compute_x_ (omp_task_problem.f90:43)
==21071== by 0x51DBCB2: __kmp_invoke_microtask (in /scratch/software/intel-2016/compilers_and_libraries_2016.3.210/linux/compiler/lib/intel64_lin/libiomp5.so)
==21071== by 0x51AA436: __kmp_invoke_task_func (kmp_runtime.c:7058)
==21071== by 0x51AB60A: __kmp_fork_call (kmp_runtime.c:2397)
==21071== by 0x5184517: __kmpc_fork_call (kmp_csupport.c:339)
==21071== by 0x403353: compute_x_ (omp_task_problem.f90:24)
==21071== by 0x402F4C: MAIN__ (omp_task_problem.f90:10)
==21071== by 0x402E1D: main (in ./a.out)
...
The line numbers of the compute_x_ function in the backtrace correspond to the !$omp task statements. These memory leaks accumulated rapidly to an amount of memory such that the program crashes. But changing the call of COMPUTE_X to
DO J = 1, 10000
CALL COMPUTE_X(M,N, X, M)
END DO
one can even use top to see that the memory requirements of the application explode.
Using gcc-6.2 for this valgrind ends up with:
==21246== LEAK SUMMARY:
==21246== definitely lost: 0 bytes in 0 blocks
==21246== indirectly lost: 0 bytes in 0 blocks
==21246== possibly lost: 8,640 bytes in 15 blocks
==21246== still reachable: 4,624 bytes in 4 blocks
==21246== suppressed: 0 bytes in 0 blocks
==21246==
where the leaks are only from the first initialization of the OpenMP runtime system.
So my question is: Why does the Intel Compiler/Intel OpenMP runtime system produce theses leaks or alternatively is there an error in the way I have
designed the task parallelism.