On Mon, 2013-01-14 at 12:00 -0500, users-requ...@open-mpi.org wrote: > Could you try to run your serial program in Valgrind and see if it > reports any erroneous memory access attempts? It could be that GCC's > implementation of the automatic allocation is broken and that OMPI's > intervention in the memory management process only exposes an already > existing problem. Well, I heard about Valgrind at some time but I am not comfortable in using it. Anyway, I simply considered the following code > PROGRAM main > > TYPE :: test_typ > REAL, ALLOCATABLE :: a(:) > END TYPE > > TYPE(test_typ) :: xx, yy > TYPE(test_typ), ALLOCATABLE :: conc(:) > > xx = test_typ( [1.0] ) > yy = test_typ( [1.0,2.0,3.0] ) > > conc = [ xx, yy ] > > END PROGRAM main and built it with 'gfortran -g test.f90 -o test'. Subsequently, I run it in Valgrind, 'valgrind --track-origins=yes ./test'. The unpleasant result is: > ==19519== Memcheck, a memory error detector > ==19519== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al. > ==19519== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info > ==19519== Command: ./test > ==19519== > ==19519== Conditional jump or move depends on uninitialised value(s) > ==19519== at 0x401030: MAIN__ (test_conc.f90:13) > ==19519== by 0x40118B: main (test_conc.f90:15) > ==19519== Uninitialised value was created by a heap allocation > ==19519== at 0x4C2B3F8: malloc (in > /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) > ==19519== by 0x400DCB: MAIN__ (test_conc.f90:13) > ==19519== by 0x40118B: main (test_conc.f90:15) > ==19519== > ==19519== > ==19519== HEAP SUMMARY: > ==19519== in use at exit: 0 bytes in 0 blocks > ==19519== total heap usage: 26 allocs, 26 frees, 12,111 bytes allocated > ==19519== > ==19519== All heap blocks were freed -- no leaks are possible > ==19519== > ==19519== For counts of detected and suppressed errors, rerun with: -v > ==19519== ERROR SUMMARY: 2 errors from 1 contexts (suppressed: 2 from 2) Well, how to interpret ...
Thanks for that very useful advice. As far as I can see, there seems to be something wrong with GCC's array-constructor implementation when allocatables are invoked. Cheers, Stefan
