[Bug fortran/54784] [OOP] allocation of extended types with polymorphic allocatable members

["jkozdon at gmail dot com" <gcc-bugzilla@gcc.gnu.org>]

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

--- Comment #2 from Jeremy Kozdon <jkozdon at gmail dot com> 2012-10-02 22:14:57 UTC ---
So there is actually two different bugs, one is the invalid memory reference
which happens when you don't allocate in order.

There is a second, the one I was really trying to report, and that's when
allocating in my original example type(block1d) before type(block2d), namely
the call
  call d%addBlock(1,b1)
  call d%addBlock(2,b2)
as opposed to
  call d%addBlock(1,b2)
  call d%addBlock(2,b1)

This gives the error:
a.out(4678) malloc: *** error for object 0x7fff82ec09be: pointer being freed
was not allocated
*** set a breakpoint in malloc_error_break to debug

Program received signal SIGABRT: Process abort signal.

Backtrace for this error:
#0  0x100004fbe
#1  0x1000056d4
#2  0x7fff82f1f1b9
Abort trap

(In reply to comment #1)
> Thanks for reporting this. I can reproduce it with 4.7 and trunk. Here is a
> reduced test case:
> 
> program bug
>   implicit none
> 
>   type :: block
>     real, allocatable :: fields
>   end type
> 
>   type :: list
>     class(block),allocatable :: B
>   end type
> 
>   type :: domain
>     type(list),dimension(2) :: L
>   end type
> 
>   type(domain) :: d
>   type(block) :: b1
> 
>   allocate(d%L(2)%B,source=b1)
> 
> end program  bug 
> 
> 
> 
> This fails at runtime with:
> 
> Program received signal SIGSEGV: Segmentation fault - invalid memory reference.
> 
> Backtrace for this error:
> #0  0x7F379D1FDA97
> #1  0x7F379D1FE074
> #2  0x7F379C72ED9F
> #3  0x400804 in __copy_bug_Block at bug.f90:9
> #4  0x40097C in bug at bug.f90:19 (discriminator 2)
> Segmentation fault
> 
> 
> valgrind shows:
> 
> ==11046== Invalid read of size 8
> ==11046==    at 0x400804: __copy_bug_Block (bug.f90:9)
> ==11046==    by 0x40097C: MAIN__ (bug.f90:19)
> ==11046==    by 0x400A88: main (bug.f90:21)
> ==11046==  Address 0x0 is not stack'd, malloc'd or (recently) free'd