$ uname -a Linux localhost.localdomain 3.1.0-7.fc16.i686.PAE #1 SMP Tue Nov 1 20:53:45 UTC 2011 i686 i686 i386 GNU/Linux $ gfortran --version GNU Fortran (GCC) 4.6.2 20111027 (Red Hat 4.6.2-1) $ cat testprog.f95 MODULE M IMPLICIT NONE TYPE T1 REAL (KIND=8), ALLOCATABLE :: A(:) REAL (KIND=8), ALLOCATABLE :: B(:) END TYPE T1 TYPE T2 TYPE(T1), ALLOCATABLE :: S1 END TYPE T2 TYPE T3 TYPE(T2), ALLOCATABLE :: S2(:) END TYPE T3 END MODULE M PROGRAM TEST USE M IMPLICIT NONE TYPE(T3) :: S3 WRITE (0,*) '## 1 ##' ALLOCATE ( S3%S2(10) ) WRITE (0,*) '## 2 ##' DEALLOCATE ( S3%S2 ) WRITE (0,*) '## 3 ##' END PROGRAM TEST $ gfortran -Wall testprog.f95 -o testprog $ ./testprog ## 1 ## ## 2 ## Segmentation fault (core dumped) ?? The WRITE statements show that the SIGSEGV occurs on the DEALLOCATE statement. Why? It seems to be something to do with the heirarchy of types with allocatable components. If this is made simpler, then the problem goes away !?!
Can you upgrade to latest release on the 4.7 branch or the development branch for 4.8? valgrind shows that 4.6 has issues while the newer branches appear to be fine. The 4.7 and 4.8 branches give troutmask:sgk[221] gfc4x -o z foo.f90 && valgrind ./z ==25491== Memcheck, a memory error detector ==25491== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al. ==25491== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info ==25491== Command: ./z ==25491== ## 1 ## ## 2 ## ## 3 ## ==25491== ==25491== HEAP SUMMARY: ==25491== in use at exit: 0 bytes in 0 blocks ==25491== total heap usage: 17 allocs, 17 frees, 3,607 bytes allocated ==25491== ==25491== All heap blocks were freed -- no leaks are possible ==25491== ==25491== For counts of detected and suppressed errors, rerun with: -v ==25491== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 5 from 1) while the 4.6 branch gives troutmask:sgk[222] gfc46 -o z foo.f90 && valgrind ./z ==25502== Memcheck, a memory error detector ==25502== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al. ==25502== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info ==25502== Command: ./z ==25502== ## 1 ## ## 2 ## ==25502== Invalid read of size 8 ==25502== at 0x400D66: MAIN__ (in /usr/home/sgk/tmp/z) ==25502== by 0x4010BA: main (in /usr/home/sgk/tmp/z) ==25502== Address 0x1efd340 is 0 bytes after a block of size 80 alloc'd ==25502== at 0x100539B: malloc (in /usr/local/lib/valgrind/vgpreload_memcheck-amd64-freebsd.so) ==25502== by 0x400BCE: MAIN__ (in /usr/home/sgk/tmp/z) ==25502== by 0x4010BA: main (in /usr/home/sgk/tmp/z) ==25502== ==25502== Invalid write of size 8 ==25502== at 0x400D91: MAIN__ (in /usr/home/sgk/tmp/z) ==25502== by 0x4010BA: main (in /usr/home/sgk/tmp/z) ==25502== Address 0x1efd340 is 0 bytes after a block of size 80 alloc'd ==25502== at 0x100539B: malloc (in /usr/local/lib/valgrind/vgpreload_memcheck-amd64-freebsd.so) ==25502== by 0x400BCE: MAIN__ (in /usr/home/sgk/tmp/z) ==25502== by 0x4010BA: main (in /usr/home/sgk/tmp/z) ==25502== ==25502== Invalid read of size 8 ==25502== at 0x400D7A: MAIN__ (in /usr/home/sgk/tmp/z) ==25502== by 0x4010BA: main (in /usr/home/sgk/tmp/z) ==25502== Address 0x1efd358 is not stack'd, malloc'd or (recently) free'd ==25502== ==25502== Invalid free() / delete / delete[] / realloc() ==25502== at 0x100516E: free (in /usr/local/lib/valgrind/vgpreload_memcheck-amd64-freebsd.so) ==25502== by 0x400D85: MAIN__ (in /usr/home/sgk/tmp/z) ==25502== by 0x4010BA: main (in /usr/home/sgk/tmp/z) ==25502== Address 0x90 is not stack'd, malloc'd or (recently) free'd ==25502== ## 3 ## ==25502== ==25502== HEAP SUMMARY: ==25502== in use at exit: 0 bytes in 0 blocks ==25502== total heap usage: 17 allocs, 20 frees, 3,751 bytes allocated ==25502== ==25502== All heap blocks were freed -- no leaks are possible ==25502== ==25502== For counts of detected and suppressed errors, rerun with: -v ==25502== ERROR SUMMARY: 18 errors from 4 contexts (suppressed: 5 from 1) It is likely that this will not be fixed as there are too few developers and too many issues on the newer branches.
I confirm that the test runs under valgrind without error from 4.7.3 up to trunk. Gcc 4.6 is no longer maintained, closing as fixed.