FWIW, I can replicate the behavior with gfortran 4.7.2:
- program runs "fine" with no MPI_Init/MPI_Finalize
- program dumps core when MPI_Init/MPI_Finalize are called (at the "conc = [ xx, yy ]" statement)
I notice that even if I disable Open MPI's memory hooking, the coredump still occurs.
Sidenote: there's a few ways to disable OMPI's memory hooking; one of the easiest is to set the environment variable FAKEROOTKEY to any value, because OMPI disables its memory hooking in Debian Fakeroot environments. For example:
% setenv FAKEROOTKEY 0
% mpifort -g arrays.f90 && ./a.out
*** glibc detected *** ./a.out: free(): invalid pointer: 0x000000369ef9cf48 ***
Specifically: with OMPI's memory hooking disabled, we don't modify the behavior of malloc/free/memalign/realloc.
I'm not sure what Open MPI is doing to anger the gfortran gods, but I did note that when I run the program without MPI_Init/MPI_Finalize, valgrind complains:
==7269== Conditional jump or move depends on uninitialised value(s)
==7269== at 0x4015B0: MAIN__ (arrays.f90:20)
==7269== by 0x401795: main (arrays.f90:26)
Line 20 is the "conc = [ xx, yy ]" statement.
I'm not enough of a Fortran guru to know what that means (to my eyes, xx and yy were just initialized above that -- perhaps it's complaining about conc?), but there you go. :-)
On Jan 14, 2013, at 6:08 AM, Stefan Mauerberger <stefan.mauerberger_at_[hidden]> wrote:
> Well, I missed to emphasize one thing: It is my intension to exploit
> F2003's lhs-(re)allocate feature. Meaning, it is totally legal in F03 to
> write something like that:
> integer, allocatable :: array(:)
> array = [ 1,2,3,4 ]
> array = [ 1 ]
> where 'array' gets automatically (re)allocated. One more thing I should
> mention: In case 'array' is manually allocate, everything is fine.
> Ok, lets do a little case study and make my suggested minimal example a
> little more exhaustive:
> PROGRAM main
> IMPLICIT NONE
> !INCLUDE 'mpif.h'
> INTEGER :: ierr
> TYPE :: test_typ
> REAL, ALLOCATABLE :: a(:)
> END TYPE
> TYPE(test_typ) :: xx, yy
> TYPE(test_typ), ALLOCATABLE :: conc(:)
> !CALL mpi_init( ierr )
> xx = test_typ( a=[1.0] )
> yy = test_typ( a=[2.0,1.0] )
> conc = [ xx, yy ]
> WRITE(*,*) SIZE(conc)
> !CALL mpi_finalize( ierr )
> END PROGRAM main
> Note: For the beginning all MPI-stuff is commented out; xx and yy are
> initialized and their member-variable 'a' is allocated.
> For now, assume it as purely serial. That piece of code complies and
> runs properly with:
> * gfortran 4.7.1, 4.7.2 and 4.8.0 (experimental)
> * ifort 12.1 and 13.0 (-assume realloc_lhs)
> * nagfort 5.3
> On the contrary it terminates, throwing a segfault, with
> * pgfortran 12.9
> Well, for the following lets simply drop PGI. In addition, according to
> 'The Fortran 2003 Handbook' published by Springer in 2009, the
> usage of the array constructor [...] is appropriate and valid.
> As a second step lets try to compile and run it invoking OMPI, just
> considering INCLUDE 'mpif.h':
> * gfortran: all right
> * ifort: all right
> * nagfor: all right
> Finally, lets initialize MPI by calling MPI_Init() and MPI_Finalize():
> * gfortran + OMPI: *** glibc detected *** ./a.out: free(): invalid
> pointer ...
> * gfortran + Intel-MPI: *** glibc detected *** ./a.out: free(): invalid
> pointer ...
> * ifort + OMPI: all right
> * nagfor + OMPI: all right (-thread_safe)
> Well, you are right, this is a very strong indication to blame gfortran
> for that! However, it gets even more confusing. Instead of linking
> against OMPI, the following results are obtained by invoking IBM's MPI
> * gfortran + IBM-MPI: all right
> * ifort + IBM-MPI: all right
> Isn't that weired?
> Any suggestions? Might it be useful to submit a bug-report to GCC
> users mailing list
For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/