Hmm. I'm unfortunately unable to replicate your results -- I get the same valgrind output with your test program regardless of whether I use gfortran or mpif90 (i.e., it shows the lost block). :-\

FWIW, I'm using RHEL4U4 (and U6) with gfortran 4.1.0 and Valgrind 3.4.0.


On Feb 14, 2009, at 3:17 PM, RDB wrote:

On Thursday 12 February 2009 4:30:27 pm George Bosilca wrote:
Some of the configure options changed their name for the 1.3. Here is
the updated list you should use in order to get valgrind support for
the 1.3:

--enable-memchecker --with-valgrind --with-memory-manager=none

  george.

For some reason that still doesn't work for me. I tried both
flag "--with-memory-manager=none" and "--without-memory-manager" and it
didn't seem to make any difference.

Attached is my config.log generated by configure script.

Here's what I get, when compiling with mpif90
$ /opt/openmpi/1.3/gcc/4.3/bin/mpif90 testMemchek.f90
$ valgrind --leak-check=full ./a.out
==7884== Memcheck, a memory error detector.
==7884== Copyright (C) 2002-2006, and GNU GPL'd, by Julian Seward et al. ==7884== Using LibVEX rev 1658, a library for dynamic binary translation.
==7884== Copyright (C) 2004-2006, and GNU GPL'd, by OpenWorks LLP.
==7884== Using valgrind-3.2.1, a dynamic binary instrumentation framework. ==7884== Copyright (C) 2000-2006, and GNU GPL'd, by Julian Seward et al.
==7884== For more details, rerun with: -v
==7884==
 0.55669999
==7884==
==7884== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 4 from 1)
==7884== malloc/free: in use at exit: 0 bytes in 0 blocks.
==7884== malloc/free: 0 allocs, 0 frees, 0 bytes allocated.
==7884== For counts of detected errors, rerun with: -v
==7884== All heap blocks were freed -- no leaks are possible.

This is different than if I just use gfortran:

$ gfortran43 testMemchek.f90
$ valgrind --leak-check=full ./a.out
==7892== Memcheck, a memory error detector.
==7892== Copyright (C) 2002-2006, and GNU GPL'd, by Julian Seward et al. ==7892== Using LibVEX rev 1658, a library for dynamic binary translation.
==7892== Copyright (C) 2004-2006, and GNU GPL'd, by OpenWorks LLP.
==7892== Using valgrind-3.2.1, a dynamic binary instrumentation framework. ==7892== Copyright (C) 2000-2006, and GNU GPL'd, by Julian Seward et al.
==7892== For more details, rerun with: -v
==7892==
 0.55669999
==7892==
==7892== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 4 from 1)
==7892== malloc/free: in use at exit: 40 bytes in 1 blocks.
==7892== malloc/free: 12 allocs, 11 frees, 25,892 bytes allocated.
==7892== For counts of detected errors, rerun with: -v
==7892== searching for pointers to 1 not-freed blocks.
==7892== checked 83,816 bytes.
==7892==
==7892== 40 bytes in 1 blocks are definitely lost in loss record 1 of 1
==7892==    at 0x4A05809: malloc (vg_replace_malloc.c:149)
==7892==    by 0x40083A: MAIN__ (in /home/reubendb/tmp/a.out)
==7892==    by 0x4009AB: main (fmain.c:21)
==7892==
==7892== LEAK SUMMARY:
==7892==    definitely lost: 40 bytes in 1 blocks.
==7892==      possibly lost: 0 bytes in 0 blocks.
==7892==    still reachable: 0 bytes in 0 blocks.
==7892==         suppressed: 0 bytes in 0 blocks.
==7892== Reachable blocks (those to which a pointer was found) are not shown.
==7892== To see them, rerun with: --show-reachable=yes

Here's the very simple test code:

$ cat testMemchek.f90
program testMemcheck
 real, dimension(:), pointer :: &
   mypointer
 real, dimension(3), target :: &
   mytarget
 mytarget = 2.345
 allocate(mypointer(10))
 mypointer = .5567
 print*,  mypointer(2)
 mypointer => mytarget
end program testMemcheck

Am I missing something ? Thanks.

RDB


On Feb 12, 2009, at 16:23 , Reuben D. Budiardja wrote:
On Thursday 12 February 2009 11:50:07 am Ashley Pittman wrote:
I am using OpenMPI-1.2.8 with all the default configure option. What
should I
do to be able use Valgrind with program compiled by OpenMPI ?

--
Reuben Budiardja
Dept. of Physics and Astronomy
University of Tennessee

<config.log.bz2>_______________________________________________
users mailing list
us...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/users


--
Jeff Squyres
Cisco Systems

Reply via email to