Memory leak on thread removal

Mikolaj Golub to.my.trociny at gmail.com
Sat May 16 17:05:30 UTC 2009


On Fri, 15 May 2009 13:48:51 +0200 Marius Nünnerich wrote:

 MN> On Tue, May 12, 2009 at 08:27, Mikolaj Golub <to.my.trociny at gmail.com> wrote:
 >> Hi,
 >>
 >> The code below is compiled with -fopenmp and run on FreeBSD6/7 (i386, amd64):
 >>
 >> #include <omp.h>
 >> #include <unistd.h>
 >>
 >> int n = 4, m = 2;
 >>
 >> int main () {
 >>        for (;;) {
 >>                int i;
 >>
 >>                //sleep(2);
 >> #pragma omp parallel for num_threads(m)
 >>                for(i = 0; i < 1; i++) {}
 >>
 >>                //sleep(2);
 >> #pragma omp parallel for num_threads(n)
 >>                for(i = 0; i < 1; i++) {}
 >>
 >>        }
 >>
 >>        return 0;
 >> }
 >>
 >> During the run the program's virtual memory usage constantly grows. The growth
 >> is observed only when n != m. When running the program with uncommented
 >> sleep() and observing the number of threads with 'top -H' I see in turn 2 or 4
 >> threads. So it looks like memory leak when thread is removed. Should I fill
 >> PR?

It looks like I have found the leak. The problem is in libgomp/team.c.
gomp_thread_start() does sem_init() but sem_destroy() is never called. This
patch solves the problem for me:

--- contrib/gcclibs/libgomp/team.c.orig 2009-05-16 17:32:57.000000000 +0300
+++ contrib/gcclibs/libgomp/team.c      2009-05-16 19:16:37.000000000 +0300
@@ -164,9 +164,12 @@ new_team (unsigned nthreads, struct gomp
 static void
 free_team (struct gomp_team *team)
 {
+  int i;
   free (team->work_shares);
   gomp_mutex_destroy (&team->work_share_lock);
   gomp_barrier_destroy (&team->barrier);
+  for(i = 1; i < team->nthreads; i++)
+    gomp_sem_destroy (team->ordered_release[i]);
   gomp_sem_destroy (&team->master_release);
   free (team);
 }

I am going to fill PR to gcc mainstream, but should I also register this in
FreeBSD bugtrack as gcc is part of the base?

BTW, the problem is not observed under Linux. I have not looked in Linux code
but it looks like sem_init() implementation for Linux does not do memory
allocation. The memory for the test program below grows under FreeBSD and does
not under Linux.

#include <semaphore.h>

int
main(int argc, char *argv[]) {

        sem_t sem;

        for(;;) { sem_init(&sem, 0, 0);}

        return 0;
}


 MN> I can confirm this. I briefly looked through the libgomp code but
 MN> didn't see the leak. Anybody knows good tools how to investigate this?

http://freshmeat.net/projects/lmdbg

This is a small memory leak debugger. It does not provide all functionality
you can find in more sophisticated tools but is lightweight, portable and
simple in use. It was very useful when I traced this bug.

-- 
Mikolaj Golub


More information about the freebsd-hackers mailing list