[Bug fortran/56471] Program crashes when allocating a derived type with an allocatable component

["janus at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>]

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

janus at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |janus at gcc dot gnu.org
            Summary|Program crashes when        |Program crashes when
                   |allocating a derived type   |allocating a derived type
                   |with a character            |with an allocatable
                   |allocatable array           |component
                   |component.                  |

--- Comment #1 from janus at gcc dot gnu.org 2013-02-27 11:55:37 UTC ---
Reduced test case:

program main
  implicit none    
    type :: containerType
    real, dimension(10000000) ::  arrayData 
    integer, allocatable :: allo
  end type
  type (containerType),allocatable :: container
  allocate(container)
end program


Note: The allocatable component does not have to be CHARACTER, but the array
needs to be very large in order to trigger the error. The generated code is:

      container = 0B;
      if ((logical(kind=4)) __builtin_expect ((integer(kind=8)) (container !=
0B), 0))
        {
          _gfortran_runtime_error_at (...);
        }
      else
        {
          container = (struct containertype *) __builtin_malloc (40000008);
          if ((logical(kind=4)) __builtin_expect ((integer(kind=8)) (container
== 0B), 0))
            {
              _gfortran_os_error (...);
            }
        }
      container->allo = 0B;
      {
        struct containertype containertype.0;

        if (container != 0B) goto L.1;
        container = (struct containertype *) __builtin_calloc (1, 40000008);
        L.1:;
        containertype.0.allo = 0B;
        *container = containertype.0;
      }


I don't really understand why 'container' is being allocated twice: Once with
__builtin_malloc and once with __builtin_calloc. Looks like we're leaking
memory here.

Valgrind reports:

==28612== Warning: client switching stacks?  SP change: 0x7fefffbe0 -->
0x7fc9da1d0
==28612==          to suppress, use: --max-stackframe=40000016 or greater
==28612== Invalid write of size 8
==28612==    at 0x4008E5: MAIN__ (in /home/jweil/GSoC/PRs/56471/a.out)
==28612==    by 0x4009D2: main (in /home/jweil/GSoC/PRs/56471/a.out)
==28612==  Address 0x7fc9da1c8 is on thread 1's stack
==28612== 
==28612== Can't extend stack to 0x7fc9d95e0 during signal delivery for thread
1:
==28612==   no stack segment
==28612== 
==28612== Process terminating with default action of signal 11 (SIGSEGV)
==28612==  Access not within mapped region at address 0x7FC9D95E0
==28612==    at 0x4008E5: MAIN__ (in /home/jweil/GSoC/PRs/56471/a.out)
==28612==  If you believe this happened as a result of a stack
==28612==  overflow in your program's main thread (unlikely but
==28612==  possible), you can try to increase the size of the
==28612==  main thread stack using the --main-stacksize= flag.
==28612==  The main thread stack size used in this run was 8388608.


Indeed the segfault seems to be due to a stack overflow.