On Sat, May 16, 2009 at 19:05, Mikolaj Golub <to.my.troc...@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.troc...@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.
_______________________________________________
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
