Memory leak on thread removal

[Marius Nünnerich]

On Sat, May 16, 2009 at 19:05, Mikolaj Golub <to.my.trociny at gmail.com> wrote:
>
> 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;
> }

Wow! Thanks for tracking this down. I think you can file both PR's so
that FreeBSD can include your patch before it comes in via upstream.

>
>
>  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.

Thanks, I'll take a look at it.