Date: Sat, 16 May 2009 20:21:32 +0000 From: Pieter de Goeje <pieter@degoeje.nl> To: freebsd-hackers@freebsd.org Cc: =?iso-8859-1?q?N=FCnnerich?= <marius@nuenneri.ch>, Mikolaj Golub <to.my.trociny@gmail.com>, Marius Subject: Re: Memory leak on thread removal Message-ID: <200905162021.32545.pieter@degoeje.nl> In-Reply-To: <86k54hvuzv.fsf@kopusha.onet> References: <814ovqn8dp.fsf@zhuzha.ua1> <b649e5e0905150448m52d0a802h50c298e529031825@mail.gmail.com> <86k54hvuzv.fsf@kopusha.onet>
next in thread | previous in thread | raw e-mail | index | archive | help
On Saturday 16 May 2009 17:05:24 Mikolaj Golub wrote:
> On Fri, 15 May 2009 13:48:51 +0200 Marius N=FCnnerich wrote:
>
> MN> On Tue, May 12, 2009 at 08:27, Mikolaj Golub <to.my.trociny@gmail.co=
m>=20
wrote:
> >> Hi,
> >>
> >> The code below is compiled with -fopenmp and run on FreeBSD6/7 (i386,
> >> amd64):
> >>
> >> #include <omp.h>
> >> #include <unistd.h>
> >>
> >> int n =3D 4, m =3D 2;
> >>
> >> int main () {
> >> for (;;) {
> >> int i;
> >>
> >> //sleep(2);
> >> #pragma omp parallel for num_threads(m)
> >> for(i =3D 0; i < 1; i++) {}
> >>
> >> //sleep(2);
> >> #pragma omp parallel for num_threads(n)
> >> for(i =3D 0; i < 1; i++) {}
> >>
> >> }
> >>
> >> return 0;
> >> }
> >>
> >> During the run the program's virtual memory usage constantly grows. T=
he
> >> growth is observed only when n !=3D 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. Th=
is
> patch solves the problem for me:
>
> --- contrib/gcclibs/libgomp/team.c.orig 2009-05-16 17:32:57.000000000 +03=
00
> +++ contrib/gcclibs/libgomp/team.c 2009-05-16 19:16:37.000000000 +03=
00
> @@ -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 =3D 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.
Note that libgomp uses it's own implementation of POSIX semaphores (using=20
phtread mutexes) instead of FreeBSD's sem(4). If the program below is run=20
against FreeBSD's implementation, it quickly stops growing because there is=
a=20
limit on the number of allocated semaphores.
It would be interesting to see if there are any differences performance wis=
e=20
between the two. If the native version is faster, it might be another reaso=
n=20
to include sem(4) in the GENERIC kernel...
>
> #include <semaphore.h>
>
> int
> main(int argc, char *argv[]) {
>
> sem_t sem;
>
> for(;;) { sem_init(&sem, 0, 0);}
>
> return 0;
> }
=2D-
Pieter de Goeje
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200905162021.32545.pieter>