[Bug fortran/55867] New: Segmentation fault on DEALLOCATION of type with ALLOCATABLE components

[Bug fortran/55867] New: Segmentation fault on DEALLOCATION of type with ALLOCATABLE components

[gilbert.scott at easynet dot co.uk]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55867

             Bug #: 55867
           Summary: Segmentation fault on DEALLOCATION of type with
                    ALLOCATABLE components
    Classification: Unclassified
           Product: gcc
           Version: 4.6.2
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: gilbert.scott@easynet.co.uk


$ 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 !?!

[Bug fortran/55867] Segmentation fault on DEALLOCATION of type with ALLOCATABLE components

[kargl at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55867

kargl at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |WAITING
   Last reconfirmed|                            |2013-01-03
                 CC|                            |kargl at gcc dot gnu.org
      Known to work|                            |4.7.2, 4.8.0
     Ever Confirmed|0                           |1
      Known to fail|                            |4.6.4

--- Comment #1 from kargl at gcc dot gnu.org 2013-01-03 17:43:44 UTC ---
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.

[Bug fortran/55867] Segmentation fault on DEALLOCATION of type with ALLOCATABLE components

[dominiq at lps dot ens.fr]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55867

Dominique d'Humieres <dominiq at lps dot ens.fr> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |RESOLVED
         Resolution|---                         |FIXED

--- Comment #2 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
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.