Strange memory leak in utterly simple code

General OpenMP discussion

Strange memory leak in utterly simple code

Postby ciccio » Wed May 21, 2008 10:15 am

Hi all,

I noticed a memory leak in a simple piece of code which you can find below together with a valgrind output.
The leak appeared on fedora, scientifc linux, mandriva. In debian there is no leak. Is it because I am doing something wrong?

Thanks

Code: Select all
#include <iostream>
int main() {
  double a(0.0), b(0.0);
#pragma omp parallel for default(shared) schedule(static) reduction(+:a) reduction(+:b)
    for (int i = 100; i >= 0; --i) {
      a += (double) i;
      b += 1.0/i;
    }
  std::cout << a << " " << b << std::endl;
  return 0;
}

Code: Select all
[ ]$ g++ -ggdb --openmp memleak.cpp
[ ]$ valgrind --leak-check=full --show-reachable=yes ./a.out
==32627== Memcheck, a memory error detector.
==32627== Copyright (C) 2002-2007, and GNU GPL'd, by Julian Seward et al.
==32627== Using LibVEX rev 1804, a library for dynamic binary translation.
==32627== Copyright (C) 2004-2007, and GNU GPL'd, by OpenWorks LLP.
==32627== Using valgrind-3.3.0, a dynamic binary instrumentation framework.
==32627== Copyright (C) 2000-2007, and GNU GPL'd, by Julian Seward et al.
==32627== For more details, rerun with: -v
==32627==
5050 inf
==32627==
==32627== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 2 from 1)
==32627== malloc/free: in use at exit: 328 bytes in 2 blocks.
==32627== malloc/free: 5 allocs, 3 frees, 1,032 bytes allocated.
==32627== For counts of detected errors, rerun with: -v
==32627== searching for pointers to 2 not-freed blocks.
==32627== checked 8,585,408 bytes.
==32627==
==32627== 24 bytes in 1 blocks are still reachable in loss record 1 of 2
==32627==    at 0x4C1ED1B: malloc (in /usr/lib64/valgrind/amd64-linux/vgpreload_memcheck.so)
==32627==    by 0x4C1EE64: realloc (in /usr/lib64/valgrind/amd64-linux/vgpreload_memcheck.so)
==32627==    by 0x53AB288: (within /usr/lib64/libgomp.so.1.0.0)
==32627==    by 0x53AD4A0: (within /usr/lib64/libgomp.so.1.0.0)
==32627==    by 0x400CBC: main (memleak.cpp:3)
==32627==
==32627==
==32627== 304 bytes in 1 blocks are possibly lost in loss record 2 of 2
==32627==    at 0x4C1DE2C: calloc (in /usr/lib64/valgrind/amd64-linux/vgpreload_memcheck.so)
==32627==    by 0x400FE62: _dl_allocate_tls (dl-tls.c:300)
==32627==    by 0x57C3B41: pthread_create@@GLIBC_2.2.5 (in /lib64/libpthread-2.7.so)
==32627==    by 0x53AD3BE: (within /usr/lib64/libgomp.so.1.0.0)
==32627==    by 0x400CBC: main (memleak.cpp:3)
==32627==
==32627== LEAK SUMMARY:
==32627==    definitely lost: 0 bytes in 0 blocks.
==32627==      possibly lost: 304 bytes in 1 blocks.
==32627==    still reachable: 24 bytes in 1 blocks.
==32627==         suppressed: 0 bytes in 0 blocks.
ciccio
 
Posts: 8
Joined: Tue Jan 29, 2008 6:57 am

Re: Strange memory leak in utterly simple code

Postby ejd » Wed May 21, 2008 4:38 pm

I see nothing wrong with your program (except maybe the division by zero - which shouldn't cause a memory leak). I tried two different tools (on Solaris) to see what they reported and I saw nothing reported for your program. However, if I am reading the Valgrind report correctly, it looks like the problem is in libgomp.so. You might want to take this over to the g++ forum and ask the question there.
ejd
 
Posts: 1025
Joined: Wed Jan 16, 2008 7:21 am

Re: Strange memory leak in utterly simple code

Postby ciccio » Thu May 22, 2008 6:16 am

Thanks,

bug reported.
ciccio
 
Posts: 8
Joined: Tue Jan 29, 2008 6:57 am


Return to Using OpenMP

Who is online

Users browsing this forum: Yahoo [Bot] and 2 guests