Compiling the following piece of code shows a memoryleak when investigated with valgrind. int main() { #pragma omp parallel for for (int i = 100; i >= 0; --i) { } return 0; } Below you find everything you need to know (i think). If something is missing, let me know. Regards Klaas [klaas@talvin10 openmp]$ g++ -v Using built-in specs. Target: x86_64-manbo-linux-gnu Configured with: ../configure --prefix=/usr --libexecdir=/usr/lib --with-slibdir=/lib64 --mandir=/usr/share/man --infodir=/usr/share/info --enable-checking=release --enable-languages=c,c++,ada,fortran,objc,obj-c++,java --host=x86_64-manbo-linux-gnu --with-cpu=generic --with-system-zlib --enable-threads=posix --enable-shared --enable-long-long --enable-__cxa_atexit --disable-libunwind-exceptions --enable-clocale=gnu --enable-java-awt=gtk --with-java-home=/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre --enable-gtk-cairo --disable-libjava-multilib --enable-ssp --disable-libssp Thread model: posix gcc version 4.2.3 (4.2.3-6mnb1) [klaas@talvin10 openmp]$ cat memleak.cpp int main() { #pragma omp parallel for for (int i = 100; i >= 0; --i) { } return 0; } [klaas@talvin10 openmp]$ g++ --openmp memleak.cpp [klaas@talvin10 openmp]$ valgrind --leak-check=full --show-reachable=yes ./a.out ==11971== Memcheck, a memory error detector. ==11971== Copyright (C) 2002-2007, and GNU GPL'd, by Julian Seward et al. ==11971== Using LibVEX rev 1804, a library for dynamic binary translation. ==11971== Copyright (C) 2004-2007, and GNU GPL'd, by OpenWorks LLP. ==11971== Using valgrind-3.3.0, a dynamic binary instrumentation framework. ==11971== Copyright (C) 2000-2007, and GNU GPL'd, by Julian Seward et al. ==11971== For more details, rerun with: -v ==11971== ==11971== ==11971== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 2 from 1) ==11971== malloc/free: in use at exit: 328 bytes in 2 blocks. ==11971== malloc/free: 5 allocs, 3 frees, 1,032 bytes allocated. ==11971== For counts of detected errors, rerun with: -v ==11971== searching for pointers to 2 not-freed blocks. ==11971== checked 8,585,392 bytes. ==11971== ==11971== 24 bytes in 1 blocks are still reachable in loss record 1 of 2 ==11971== at 0x4C1ED1B: malloc (in /usr/lib64/valgrind/amd64-linux/vgpreload_memcheck.so) ==11971== by 0x4C1EE64: realloc (in /usr/lib64/valgrind/amd64-linux/vgpreload_memcheck.so) ==11971== by 0x53AB288: (within /usr/lib64/libgomp.so.1.0.0) ==11971== by 0x53AD4A0: (within /usr/lib64/libgomp.so.1.0.0) ==11971== by 0x4006CF: main (in /home/klaas/devel/testing/openmp/a.out) ==11971== ==11971== ==11971== 304 bytes in 1 blocks are possibly lost in loss record 2 of 2 ==11971== at 0x4C1DE2C: calloc (in /usr/lib64/valgrind/amd64-linux/vgpreload_memcheck.so) ==11971== by 0x400FE62: _dl_allocate_tls (dl-tls.c:300) ==11971== by 0x57C3B41: pthread_create@@GLIBC_2.2.5 (in /lib64/libpthread-2.7.so) ==11971== by 0x53AD3BE: (within /usr/lib64/libgomp.so.1.0.0) ==11971== by 0x4006CF: main (in /home/klaas/devel/testing/openmp/a.out) ==11971== ==11971== LEAK SUMMARY: ==11971== definitely lost: 0 bytes in 0 blocks. ==11971== possibly lost: 304 bytes in 1 blocks. ==11971== still reachable: 24 bytes in 1 blocks. ==11971== suppressed: 0 bytes in 0 blocks. [klaas@talvin10 openmp]$
This is not a memory leak, just misunderstanding what valgrind is reporting. Memory still reachable at exit time is not a bug, all memory is freed by exit. Some libraries are instrumented with hooks that at exit time can be called from memory allocation checker (valgrind, mtrace, ...), e.g. libc, but in some cases this isn't possible at all and only very few libraries are instrumented that way. Memory leak is when something hasn't been freed, but isn't reachable anymore. The rest are just potential problems that you can analyze. In libgomp case, most of the allocations still reachable at exit time fall into the category where they really can't be freed. Remember the requirement spelled in threadprivate directive description, if the number of threads is the same between two consecutive parallel regions and two of the ICVs didn't change, then threadprivate vars must be preserved. This means a thread pool must be live whenever there was some parallel region, with the number of threads from the last parallel region. For that you need some malloced control data structures and each thread has its TLS allocaed too.
I have also some memory leak. As I'm using imagemagick and OpenMP for parallel processing. I tried to check a simple program with valgrind and it shows memory leak in some function and it's because of OPenMP. Here is the link for that discussion. Please take a look. https://www.imagemagick.org/discourse-server/viewtopic.php?f=6&t=32190