Bug 36298 - gomp contains small memoryleak
Summary: gomp contains small memoryleak
Alias: None
Product: gcc
Classification: Unclassified
Component: libgomp (show other bugs)
Version: 4.2.3
: P3 major
Target Milestone: ---
Assignee: Not yet assigned to anyone
Keywords: openmp
Depends on:
Reported: 2008-05-22 07:57 UTC by Klaas
Modified: 2017-06-22 06:17 UTC (History)
1 user (show)

See Also:
Known to work:
Known to fail:
Last reconfirmed:


Note You need to log in before you can comment on or make changes to this bug.
Description Klaas 2008-05-22 07:57:51 UTC
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.


[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- --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== 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== 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== 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== 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]$
Comment 1 Jakub Jelinek 2008-05-23 17:03:07 UTC
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.
Comment 2 Rahul OB 2017-06-22 06:17:52 UTC
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.