| Issue |
158659
|
| Summary |
[flang][OpenMP] Memory leak in first private declaration of a derived type.
|
| Labels |
flang
|
| Assignees |
|
| Reporter |
scamp-nvidia
|
Consider the following code:
```
PROGRAM DRIVER
use omp_lib
IMPLICIT NONE
INTEGER, PARAMETER :: NVAL = 2000
TYPE TCONTAINER
REAL(KIND=8), ALLOCATABLE :: ARR(:)
END TYPE TCONTAINER
TYPE(TCONTAINER) :: obj
INTEGER :: idx
ALLOCATE (obj%ARR(NVAL))
do idx=1,4
!$OMP PARALLEL FIRSTPRIVATE (obj)
write(*,*), 'thread', omp_get_thread_num()
!$OMP END PARALLEL
enddo
DEALLOCATE (obj%ARR)
END PROGRAM DRIVER
```
Compiling with a recent version of upstream Flang and running this code with valgrind on an icelake machine (x86):
```
[scamp]$ flang test.F90 -o test -fopenmp -g
[scamp]$ export OMP_NUM_THREADS=2
[scamp]$ valgrind --leak-check=full ./test
==3579486== Memcheck, a memory error detector
==3579486== Copyright (C) 2002-2024, and GNU GPL'd, by Julian Seward et al.
==3579486== Using Valgrind-3.25.1 and LibVEX; rerun with -h for copyright info
==3579486== Command: ./test
==3579486==
thread 0
thread 1
thread 0
thread 1
thread 0
thread 1
thread 0
thread 1
==3579486==
==3579486== HEAP SUMMARY:
==3579486== in use at exit: 210,753 bytes in 24 blocks
==3579486== total heap usage: 796 allocs, 772 frees, 1,756,205 bytes allocated
==3579486==
==3579486== 64,000 bytes in 4 blocks are definitely lost in loss record 11 of 13
==3579486== at 0x4C3E2E1: malloc (vg_replace_malloc.c:446)
==3579486== by 0x501C0E6: Fortran::runtime::Descriptor::Allocate(long*) (in /llvm/lib/clang/22/lib/x86_64-unknown-linux-gnu/libflang_rt.runtime.so)
==3579486== by 0x4FD3B47: Fortran::runtime::AssignTicket::Continue(Fortran::runtime::WorkQueue&) (in /llvm/lib/clang/22/lib/x86_64-unknown-linux-gnu/libflang_rt.runtime.so)
==3579486== by 0x4FD1ABC: Fortran::runtime::DerivedAssignTicket<true>::Continue(Fortran::runtime::WorkQueue&) (in /llvm/lib/clang/22/lib/x86_64-unknown-linux-gnu/libflang_rt.runtime.so)
==3579486== by 0x4FD3E6F: Fortran::runtime::AssignTicket::Continue(Fortran::runtime::WorkQueue&) (in /llvm/lib/clang/22/lib/x86_64-unknown-linux-gnu/libflang_rt.runtime.so)
==3579486== by 0x4FD65BC: _FortranAAssign (in /llvm/lib/clang/22/lib/x86_64-unknown-linux-gnu/libflang_rt.runtime.so)
==3579486== by 0x40014E4: _QQmain..omp_par (test.F90:8)
==3579486== by 0x4132178: __kmp_invoke_microtask (in /llvm/lib/x86_64-unknown-linux-gnu/libomp.so)
==3579486== by 0x40AE59E: __kmp_invoke_task_func (in /llvm/lib/x86_64-unknown-linux-gnu/libomp.so)
==3579486== by 0x40A8BC4: __kmp_fork_call (in /llvm/lib/x86_64-unknown-linux-gnu/libomp.so)
==3579486== by 0x40986FC: __kmpc_fork_call (in /llvm/lib/x86_64-unknown-linux-gnu/libomp.so)
==3579486== by 0x40012DF: _QQmain (test.F90:8)
==3579486==
==3579486== 64,000 bytes in 4 blocks are definitely lost in loss record 12 of 13
==3579486== at 0x4C3E2E1: malloc (vg_replace_malloc.c:446)
==3579486== by 0x501C0E6: Fortran::runtime::Descriptor::Allocate(long*) (in /llvm/lib/clang/22/lib/x86_64-unknown-linux-gnu/libflang_rt.runtime.so)
==3579486== by 0x4FD3B47: Fortran::runtime::AssignTicket::Continue(Fortran::runtime::WorkQueue&) (in /llvm/lib/clang/22/lib/x86_64-unknown-linux-gnu/libflang_rt.runtime.so)
==3579486== by 0x4FD1ABC: Fortran::runtime::DerivedAssignTicket<true>::Continue(Fortran::runtime::WorkQueue&) (in /llvm/lib/clang/22/lib/x86_64-unknown-linux-gnu/libflang_rt.runtime.so)
==3579486== by 0x4FD3E6F: Fortran::runtime::AssignTicket::Continue(Fortran::runtime::WorkQueue&) (in /llvm/lib/clang/22/lib/x86_64-unknown-linux-gnu/libflang_rt.runtime.so)
==3579486== by 0x4FD65BC: _FortranAAssign (in /llvm/lib/clang/22/lib/x86_64-unknown-linux-gnu/libflang_rt.runtime.so)
==3579486== by 0x40014E4: _QQmain..omp_par (test.F90:8)
==3579486== by 0x4132178: __kmp_invoke_microtask (in /llvm/lib/x86_64-unknown-linux-gnu/libomp.so)
==3579486== by 0x40AE59E: __kmp_invoke_task_func (in /llvm/lib/x86_64-unknown-linux-gnu/libomp.so)
==3579486== by 0x40AD1FD: __kmp_launch_thread (in /llvm/lib/x86_64-unknown-linux-gnu/libomp.so)
==3579486== by 0x4111BF7: __kmp_launch_worker(void*) (in /llvm/lib/x86_64-unknown-linux-gnu/libomp.so)
==3579486== by 0x65521C9: start_thread (in /usr/lib64/libpthread-2.28.so)
==3579486==
==3579486== LEAK SUMMARY:
==3579486== definitely lost: 128,000 bytes in 8 blocks
==3579486== indirectly lost: 0 bytes in 0 blocks
==3579486== possibly lost: 0 bytes in 0 blocks
==3579486== still reachable: 82,753 bytes in 16 blocks
==3579486== suppressed: 0 bytes in 0 blocks
==3579486== Reachable blocks (those to which a pointer was found) are not shown.
==3579486== To see them, rerun with: --leak-check=full --show-leak-kinds=all
==3579486==
==3579486== For lists of detected and suppressed errors, rerun with: -s
==3579486== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 0 from 0)
[scamp]$
```
There's definitely a memory leak associated with the first private declaration of 'obj' at the parallel region. Analyzing the assembly with "-S" and comparing against the valgrind output, I believe for the parallel region, there's a '_FortranAAssign' that allocates at the beginning of the parallel region, but there's not corresponding free for that allocation, leading to the leak.
![]()
_______________________________________________
llvm-bugs mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
