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;
}
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
_______________________________________________
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"
