[Bug fortran/64230] [4.9/5 Regression] Segmentation fault - invalid memory reference in a compiler-generated finalizer for a complicated type hierarchy when a polymorphic variable is allocated in an external procedure.

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

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64230

janus at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |wrong-code
                 CC|                            |janus at gcc dot gnu.org

--- Comment #2 from janus at gcc dot gnu.org ---
Here is a somewhat reduced test case, which gets rid of parts of the insane
inheritance chain:


Program main
  Implicit None
  Type :: t1
  End Type
  Type, Extends (t1) :: t2
    Integer, Allocatable :: i
  End Type
  Type, Extends (t2) :: t3
    Integer, Allocatable :: j
  End Type
  Class (t1), Allocatable :: t
  Allocate (t3 :: t)
  print *,"allocated!"
  Deallocate (t)
End


$ gfortran-5.0 -g -fsanitize=undefined c0.f90 && ./a.out
 allocated!
c0.f90:1: runtime error: member access within null pointer of type 'struct t2'

Program received signal SIGSEGV: Segmentation fault - invalid memory reference.

Backtrace for this error:
#0  0x7FC890D235F7
#1  0x7FC890D23C3E
#2  0x7FC88F557D9F
#3  0x402423 in __final_main_T2 at c0.f90:1 (discriminator 12)
#4  0x4015B1 in __final_main_T3 at c0.f90:1 (discriminator 8)
#5  0x401806 in MAIN__ at c0.f90:14 (discriminator 3)
Speicherzugriffsfehler (Speicherabzug geschrieben)


The segfault obviously happens in the deallocate statement, for which
-fdump-tree-original shows the following translation:

      if (t._data == 0B)
        {
          _gfortran_runtime_error_at (...);
        }
      else
        {
          if (t._vptr->_final != 0B)
            {
              {
                struct array0_t1 desc.13;

                desc.13.dtype = 40;
                desc.13.data = (void * restrict) t._data;
                t._vptr->_final (&desc.13, t._vptr->_size, 0);
              }
            }
          __builtin_free ((void *) t._data);
        }
      t._data = 0B;
      (struct __vtype_main_T1 *) t._vptr = &__vtab_main_T1;


So, yeah, the problem is somewhere in the finalizer call ("t._vptr->_final"),
but I don't directly see where in the finalization routine it occurs (the
compiler generates a 500+ line dump for a 15-line program here).