[Bug libgomp/36298] New: gomp contains small memoryleak

[Bug libgomp/36298] New: gomp contains small memoryleak

[Klaas dot Vantournhout at UGent dot be]

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]$


-- 
           Summary: gomp contains small memoryleak
           Product: gcc
           Version: 4.2.3
            Status: UNCONFIRMED
          Severity: major
          Priority: P3
         Component: libgomp
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: Klaas dot Vantournhout at UGent dot be


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36298

[Bug libgomp/36298] gomp contains small memoryleak

[jakub at gcc dot gnu dot org]

------- Comment #1 from jakub at gcc dot gnu dot org  2008-05-23 17:03 -------
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.


-- 

jakub at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
           Keywords|                            |openmp
         Resolution|                            |INVALID


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36298