FW: Is GMP safe for using on multi core processors with openmp or pthreads?

Mon Jul 27 19:46:52 CEST 2009

Is the GMP  mpz routine safe for using on multi core processors with openmp or pthreads with the Linux malloc in glibc?  

Valgrind is reporting a memory leak in a simple GMP program when compiled with GCC 4.4 and -fopenmp

Here is the program.

login3$ cat  memory-leak.c

#include <stdlib.h>

#include <gmp.h>

#define CORES 4

#define AMAX 64

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

{

   int i;

   mpz_t array[AMAX];

#ifdef _OPENMP

#pragma omp parallel for default(shared) private(i) num_threads(CORES)

#endif

   for (i = 0 ; i < AMAX ; i++) 

      mpz_init(array[i]);

#ifdef _OPENMP

#pragma omp parallel for default(shared) private(i) num_threads(CORES)

#endif

   for (i = 0 ; i < AMAX ; i++) 

      mpz_clear(array[i]);

   exit(0);

}

Here is my environment:

login3$ cat /etc/redhat-release

CentOS release 4.7 (Final)

login3$ gcc -v

Using built-in specs.

Target: x86_64-unknown-linux-gnu

Configured with: ../configure --prefix=/opt/apps/gcc_amd/4.4.0 --enable-languages=c,c++,fortran --with-ppl=/opt/apps/gcc_amd/4.4.0 --with-cloog=/opt/apps/gcc_amd/4.4.0

Thread model: posix

gcc version 4.4.0 (GCC)

login3$ grep GNU_MP_VERSION /opt/apps/gcc_amd/4.4.0/include/gmp.h

#define __GNU_MP_VERSION 4

#define __GNU_MP_VERSION_MINOR 2

#define __GNU_MP_VERSION_PATCHLEVEL 4

login3$

GCC compiled with OpenMP and Valgrind reports memory leak

login3$ gcc -Wall -fopenmp -O0 -g -o memory-leak memory-leak.c -lgmp lm

login3$ valgrind --version

valgrind-3.4.1

login3$ valgrind --leak-check=full --show-reachable=yes --track-origins=yes  ./memory-leak

==21528== Memcheck, a memory error detector.

==21528== Using LibVEX rev 1884, a library for dynamic binary translation.

==21528== Using valgrind-3.4.1, a dynamic binary instrumentation framework.

==21528== For more details, rerun with: -v

==21528== 

==21528== 

==21528== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 10 from 5)

==21528== malloc/free: in use at exit: 2,888 bytes in 6 blocks.

==21528== malloc/free: 75 allocs, 69 frees, 8,382 bytes allocated.

==21528== For counts of detected errors, rerun with: -v

==21528== searching for pointers to 6 not-freed blocks.

==21528== checked 6,470,896 bytes.

==21528== 

==21528== 40 bytes in 1 blocks are still reachable in loss record 1 of 3

==21528==    at 0x4A075EE: malloc (vg_replace_malloc.c:207)

==21528==    by 0x4A07777: realloc (vg_replace_malloc.c:429)

==21528==    by 0x4E7E3C8: gomp_realloc (alloc.c:54)

==21528==    by 0x4E83632: gomp_team_start (team.c:358)

==21528==    by 0x400844: main (memory-leak.c:13)

==21528== 

==21528== 

==21528== 864 bytes in 3 blocks are possibly lost in loss record 2 of 3

==21528==    at 0x4A053C4: calloc (vg_replace_malloc.c:397)

==21528==    by 0x375F50D742: _dl_allocate_tls (in /lib64/ld-2.3.4.so)

==21528==    by 0x3760206792: pthread_create@@GLIBC_2.2.5 (in /lib64/tls/libpthread-2.3.4.so)

==21528==    by 0x4E833C9: gomp_team_start (team.c:420)

==21528==    by 0x400844: main (memory-leak.c:13)

==21528== 

==21528== 

==21528== 1,984 bytes in 2 blocks are still reachable in loss record 3 of 3

==21528==    at 0x4A075EE: malloc (vg_replace_malloc.c:207)

==21528==    by 0x4E7E418: gomp_malloc (alloc.c:36)

==21528==    by 0x4E836F4: gomp_team_start (team.c:190)

==21528==    by 0x400844: main (memory-leak.c:13)

==21528== 

==21528== LEAK SUMMARY:

==21528==    definitely lost: 0 bytes in 0 blocks.

==21528==      possibly lost: 864 bytes in 3 blocks.

==21528==    still reachable: 2,024 bytes in 3 blocks.

==21528==         suppressed: 0 bytes in 0 blocks.

GCC compile without OpenMP and Valgrind does not report a memory leak

login3$ gcc -Wall  -O0 -g -o memory-leak memory-leak.c -lgmp -lm

login3$ valgrind --leak-check=full --show-reachable=yes --track-origins=yes  ./memory-leak

==22533== Memcheck, a memory error detector.

==22533== Using LibVEX rev 1884, a library for dynamic binary translation.

==22533== Using valgrind-3.4.1, a dynamic binary instrumentation framework.

==22533== For more details, rerun with: -v

==22533== 

==22533== 

==22533== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 10 from 5)

==22533== malloc/free: in use at exit: 0 bytes in 0 blocks.

==22533== malloc/free: 64 allocs, 64 frees, 512 bytes allocated.

==22533== For counts of detected errors, rerun with: -v

==22533== All heap blocks were freed -- no leaks are possible.

Similar results  also using the Intel compiler

login3$ icc -v

Version 10.1

login3$ icc -openmp  -O0 -g -o memory-leak memory-leak.c -I$TACC_GMP_INC -L$TACC_GMP_LIB -lgmp -lm

memory-leak.c(15): (col. 1) remark: OpenMP DEFINED LOOP WAS PARALLELIZED.

memory-leak.c(23): (col. 1) remark: OpenMP DEFINED LOOP WAS PARALLELIZED.

login3$  valgrind --leak-check=full --show-reachable=yes --track-origins=yes  ./memory-leak

==7889== Memcheck, a memory error detector.

==7889== Using LibVEX rev 1884, a library for dynamic binary translation.

==7889== Using valgrind-3.4.1, a dynamic binary instrumentation framework.

==7889== For more details, rerun with: -v

==7889== 

==7889== Syscall param sched_setaffinity(mask) points to unaddressable byte(s)

==7889==    at 0x375F7C6559: syscall (in /lib64/tls/libc-2.3.4.so)

==7889==    by 0x522B023: __kmp_affinity_determine_capable (in /share/apps/intel/10.1/cc/lib/libguide.so)

==7889==    by 0x5217490: __kmp_env_initialize (in /share/apps/intel/10.1/cc/lib/libguide.so)

==7889==    by 0x520D5A4: __kmp_serial_initialize (in /share/apps/intel/10.1/cc/lib/libguide.so)

==7889==    by 0x52067D0: __kmp_internal_begin (in /share/apps/intel/10.1/cc/lib/libguide.so)

==7889==    by 0x51F8DE1: __kmpc_begin (in /share/apps/intel/10.1/cc/lib/libguide.so)

==7889==    by 0x400AF8: main (memory-leak.c:11)

==7889==  Address 0x0 is not stack'd, malloc'd or (recently) free'd

==7889== 

==7889== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 10 from 5)

==7889== malloc/free: in use at exit: 1,720 bytes in 5 blocks.

==7889== malloc/free: 174 allocs, 169 frees, 1,162,119 bytes allocated.

==7889== For counts of detected errors, rerun with: -v

==7889== searching for pointers to 5 not-freed blocks.

==7889== checked 12,835,600 bytes.

==7889== 

==7889== 

==7889== 568 bytes in 1 blocks are still reachable in loss record 1 of 2

==7889==    at 0x4A075EE: malloc (vg_replace_malloc.c:207)

==7889==    by 0x375F75AEE9: __fopen_internal (in /lib64/tls/libc-2.3.4.so)

==7889==    by 0x51E9D5F: __kmp_affinity_initialize (in /share/apps/intel/10.1/cc/lib/libguide.so)

==7889==    by 0x520D13C: __kmp_parallel_initialize (in /share/apps/intel/10.1/cc/lib/libguide.so)

==7889==    by 0x520A26C: __kmp_fork_call (in /share/apps/intel/10.1/cc/lib/libguide.so)

==7889==    by 0x51F8C4E: __kmpc_fork_call (in /share/apps/intel/10.1/cc/lib/libguide.so)

==7889==    by 0x400B99: main (memory-leak.c:15)

==7889== 

==7889== 

==7889== 1,152 bytes in 4 blocks are possibly lost in loss record 2 of 2

==7889==    at 0x4A053C4: calloc (vg_replace_malloc.c:397)

==7889==    by 0x375F50D742: _dl_allocate_tls (in /lib64/ld-2.3.4.so)

==7889==    by 0x3760206792: pthread_create@@GLIBC_2.2.5 (in /lib64/tls/libpthread-2.3.4.so)

==7889==    by 0x5229317: __kmp_create_monitor (in /share/apps/intel/10.1/cc/lib/libguide.so)

==7889==    by 0x520D137: __kmp_parallel_initialize (in /share/apps/intel/10.1/cc/lib/libguide.so)

==7889==    by 0x520A26C: __kmp_fork_call (in /share/apps/intel/10.1/cc/lib/libguide.so)

==7889==    by 0x51F8C4E: __kmpc_fork_call (in /share/apps/intel/10.1/cc/lib/libguide.so)

==7889==    by 0x400B99: main (memory-leak.c:15)

==7889== 

==7889== LEAK SUMMARY:

==7889==    definitely lost: 0 bytes in 0 blocks.

==7889==      possibly lost: 1,152 bytes in 4 blocks.

==7889==    still reachable: 568 bytes in 1 blocks.

==7889==         suppressed: 0 bytes in 0 blocks.

login3$ icc  -O0 -g -o memory-leak memory-leak.c -I$GMP_INC -L$GMP_LIB -lgmp lm

login3$  valgrind --leak-check=full --show-reachable=yes --track-origins=yes  ./memory-leak

==6267== Memcheck, a memory error detector.

==6267== Using LibVEX rev 1884, a library for dynamic binary translation.

==6267== Using valgrind-3.4.1, a dynamic binary instrumentation framework.

==6267== For more details, rerun with: -v

==6267== 

==6267== 

==6267== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 10 from 5)

==6267== malloc/free: in use at exit: 0 bytes in 0 blocks.

==6267== malloc/free: 64 allocs, 64 frees, 512 bytes allocated.

==6267== For counts of detected errors, rerun with: -v

==6267== All heap blocks were freed -- no leaks are possible.

I dont get the memory leak if I use Hoards malloc from http://www.cs.umass.edu/~emery/hoard/

Could there be a problem with heap contention in linuxs glibc malloc/free?  

login1$ gcc -Wall  -O0 -g -o memory-leak memory-leak.c -lgmp -lm -L. -lhoard    

login1$ valgrind --leak-check=full --show-reachable=yes --track-origins=yes  ./memory-leak

==21569== Memcheck, a memory error detector.

==21569== Using LibVEX rev 1884, a library for dynamic binary translation.

==21569== Using valgrind-3.4.1, a dynamic binary instrumentation framework.

==21569== For more details, rerun with: -v

==21569== 

==21569== 

==21569== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 10 from 5)

==21569== malloc/free: in use at exit: 0 bytes in 0 blocks.

==21569== malloc/free: 0 allocs, 0 frees, 0 bytes allocated.

==21569== For counts of detected errors, rerun with: -v

==21569== All heap blocks were freed -- no leaks are possible.

login1$

Thanks,

David

-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 474 bytes
Desc: not available
URL: <http://gmplib.org/list-archives/gmp-discuss/attachments/20090727/c6f8a4e9/attachment.bin>