2

I have difficulty trying to correct a simple OpenMP loop to avoid having a "definitely lost" memory leak from valgrind. Without OpenMP, Valgrind doesn't return problematic memory leaks while it is when OpenMP pragmas are activated. Here is an example of a simple matrix assignment that leaks:

  void assign(const Matrix& src, Matrix& dest) {
  int nr = src.rows();
  int nc = src.cols();
#pragma omp parallel for num_threads(NUM_THREADS) firstprivate(nr, nc) schedule(dynamic, 1)
  for (int32 c = 0 ; c < nc ; ++c) {
    for (int32 r = 0 ;  r < nr ; ++r)
      mat(r,c) = src(r,c);
  }

Here are the leak details:

==19732== 304 bytes in 1 blocks are definitely lost in loss record 8 of 11
==19732==    at 0x4C2FB55: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==19732==    by 0x40136D4: allocate_dtv (dl-tls.c:322)
==19732==    by 0x40136D4: _dl_allocate_tls (dl-tls.c:539)
==19732==    by 0x68A926E: allocate_stack (allocatestack.c:588)
==19732==    by 0x68A926E: pthread_create@@GLIBC_2.2.5 (pthread_create.c:539)
==19732==    by 0x647899F: ??? (in /usr/lib/x86_64-linux-gnu/libgomp.so.1.0.0)
==19732==    by 0x6474CB9: GOMP_parallel (in /usr/lib/x86_64-linux-gnu/libgomp.so.1.0.0)
==19732==    by 0x43BF6D: void assign(Matrix const&, Matrix&) (assign.h:267)
==19732==    by 0x43BB30: Matrix::Matrix(Matrix const&) (matrix.h:1351)
==19732==    by 0x43A451: DistanceTest::read_matrix(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >) (test_distance.cpp:85)
==19732==    by 0x43A702: DistanceTest::read_data() (test_distance.cpp:106)
==19732==    by 0x43DE10: test::ABTest::Run(int) (ab_test.cpp:44)

Is it a huge deal having a "definitely lost" because of OpenMP ? Is it resulting from a bad habit in my pragma writing or because of the difficulties Valgrind has studying the OpenMP framework ?

baptiste
  • 1,107
  • 2
  • 15
  • 30
  • This is most likely the same [as this question](https://stackoverflow.com/questions/6973489/valgrind-and-openmp-still-reachable-and-possibly-lost-is-that-bad) // the linked [gomp bug](https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36298). However there the memory is still reachable, which is slightly concerning in your case. See also https://stackoverflow.com/questions/17642433/why-pthread-causes-a-memory-leak – Zulan May 09 '17 at 14:19
  • Can you reproduce that with a [mcve]? – Zulan May 09 '17 at 14:19
  • It's been so many years and libgomp still cannot create the Linux-specific TLS without messing up with Valgrind (or the Valgrind people would not agree that what libgomp does is actually valid and merits an exclusion)... Just ignore Valgrind complaints that contain `GOMP_whatever` in the call stack. – Hristo Iliev May 09 '17 at 15:13
  • I just checked the behaviour of allocate_dtv under valgrind in debian 8.8 on the valgrind test none/tests/tls. – phd May 09 '17 at 18:59
  • (continued) I see the allocation of the dtv, and afterwards, the memory is freed via via pthread_join/free_tcb/queue_stack/__free_stacks/__GI__dl_deallocate_tls. This all seems to work properly. You might maybe read in the user manual the info about --sim-hints=no-nptl-pthread-stackcache. You might also do native debugging, and check if the memory allocated by allocate_dtv is effectively freed (or not freed). – phd May 09 '17 at 19:06
  • @Zulan that's what bothered me as well. The "definitely lost" is annoying. I will try to make a simple example. – baptiste May 10 '17 at 09:46
  • The thing that annoys me there is that without OpenMP I don't have any leak, and with it some appears. I tried to do a basic OpenMP for loop and I don't have any leak so it should come from my side and not OpenMP. I will update here if I find what happens – baptiste May 10 '17 at 10:05

0 Answers0