[Bug fortran/109066] New: Segfault when using defined assignment

[Bug fortran/109066] New: Segfault when using defined assignment

[abensonca at gcc dot gnu.org]

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

            Bug ID: 109066
           Summary: Segfault when using defined assignment
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
          Assignee: unassigned at gcc dot gnu.org
          Reporter: abensonca at gcc dot gnu.org
  Target Milestone: ---

The following code (compiled using current trunk), when run, causes a segfault,
and valgrind complains about an invalid read. The code appears correct to me,
and runs correctly (no segfault, no warnings from valgrind) when compiled with
ifort.

module Input_Parameters_Bug
  public

  type :: resourceManager
     integer   :: counter=0 ! Remove this to resolve segfault
   contains
     procedure :: resourceManagerAssign
     generic   :: assignment(=) => resourceManagerAssign
  end type resourceManager

  type hdf5Object
     private
     type   (resourceManager) :: objectManager
   contains
     procedure :: openGroup =>IO_HDF5_Open_Group
    ! procedure :: h5Assign  ! Add this defined assignment to avoid segfault.
    ! generic   :: assignment(=) => h5Assign
  end type hdf5Object

  interface hdf5Object
     module procedure hdf5Constructor
  end interface hdf5Object

  type :: inputParameters
     private
     type(hdf5Object), pointer :: outputParameters => null() ! Make this
allocatable instead of pointer to resolve segfault
  end type inputParameters

  interface inputParameters
     module procedure inputParametersConstructorNode
  end interface inputParameters

contains

  subroutine resourceManagerAssign(to,from)
    implicit none
    class(resourceManager), intent(  out) :: to
    class(resourceManager), intent(in   ) :: from
    to%counter=from%counter+1
    write (0,*) "ASSIGN",to%counter    
    return
  end subroutine resourceManagerAssign

  function hdf5Constructor() result(self)
    implicit none
    type(hdf5Object) :: self
    return
  end function hdf5Constructor

  function IO_HDF5_Open_Group(inObject) result (self)
    implicit none
    type(hdf5Object) :: self
    class(hdf5Object), intent(in   ) :: inObject
    write (0,*) "OPEN"
    return
  end function IO_HDF5_Open_Group

  subroutine h5Assign(to,from)
    implicit none
    class(hdf5Object), intent(  out) :: to
    class(hdf5Object), intent(in   ) :: from
    write (0,*) "ASSIGN H5"
    to%objectManager=from%objectManager
    return
  end subroutine h5Assign

  function inputParametersConstructorNode(outputParametersGroup) result(self)
    implicit none
    type(inputParameters) :: self
    type(hdf5Object     ), intent(in   ) :: outputParametersGroup
    allocate(self%outputParameters)
    write (0,*) "START"
    self%outputParameters=outputParametersGroup%openGroup()
    write (0,*) "STOP"
    return
  end function inputParametersConstructorNode

end module Input_Parameters_Bug

program Test_Parameters_Bug
  use :: Input_Parameters_Bug
  implicit none
  type(hdf5Object)          :: outputFile
  type(inputParameters) :: testParameters
  outputFile=hdf5Object()
  write (0,*) "CALL"
  testParameters=inputParameters(outputFile)
end program Test_Parameters_Bug


$ gfortran bug.F90 -g
$ valgrind --track-origins=yes ./a.out 
==19625== Memcheck, a memory error detector
==19625== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==19625== Using Valgrind-3.17.0 and LibVEX; rerun with -h for copyright info
==19625== Command: ./a.out
==19625== 
 ASSIGN           1
 CALL
 START
 OPEN
==19625== Use of uninitialised value of size 8
==19625==    at 0x4012DF:
__input_parameters_bug_MOD_inputparametersconstructornode (bug.F90:73)
==19625==    by 0x4017D4: MAIN__ (bug.F90:87)
==19625==    by 0x401812: main (bug.F90:81)
==19625==  Uninitialised value was created by a stack allocation
==19625==    at 0x401206:
__input_parameters_bug_MOD_inputparametersconstructornode (bug.F90:67)
==19625== 

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

Backtrace for this error:
#0  0x4e161ef in ???
#1  0x4012df in __input_parameters_bug_MOD_inputparametersconstructornode
        at
/data001/abenson/Galacticus/galacticus_gfortranFinalization/bug.F90:73
#2  0x4017d4 in test_parameters_bug
        at
/data001/abenson/Galacticus/galacticus_gfortranFinalization/bug.F90:87
#3  0x401812 in main
        at
/data001/abenson/Galacticus/galacticus_gfortranFinalization/bug.F90:81
==19625== 
==19625== Process terminating with default action of signal 11 (SIGSEGV)
==19625==    at 0x4E1613E: raise (in
/home/abenson/Galacticus/Tools/lib/libc-2.12.1.so)
==19625==    by 0x4E161EF: ??? (in
/home/abenson/Galacticus/Tools/lib/libc-2.12.1.so)
==19625==    by 0x4012DE:
__input_parameters_bug_MOD_inputparametersconstructornode (bug.F90:73)
==19625==    by 0x4017D4: MAIN__ (bug.F90:87)
==19625==    by 0x401812: main (bug.F90:81)
==19625== 
==19625== HEAP SUMMARY:
==19625==     in use at exit: 5,448 bytes in 18 blocks
==19625==   total heap usage: 22 allocs, 4 frees, 13,588 bytes allocated
==19625== 
==19625== LEAK SUMMARY:
==19625==    definitely lost: 0 bytes in 0 blocks
==19625==    indirectly lost: 0 bytes in 0 blocks
==19625==      possibly lost: 0 bytes in 0 blocks
==19625==    still reachable: 5,448 bytes in 18 blocks
==19625==         suppressed: 0 bytes in 0 blocks
==19625== Rerun with --leak-check=full to see details of leaked memory
==19625== 
==19625== For lists of detected and suppressed errors, rerun with: -s
==19625== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 4 from 4)
Segmentation fault

This segfault goes away if I:
1. Remove the "counter" variable from type "resourceManager"
2. Add a defined assignment for type "hdf5Object"
3. Change the "outputParameters" variable from a pointer to an allocatable.

[Bug fortran/109066] Segfault when using defined assignment

[pault at gcc dot gnu.org]

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

Paul Thomas <pault at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|                            |2023-03-09
                 CC|                            |pault at gcc dot gnu.org
             Status|UNCONFIRMED                 |NEW
            Version|unknown                     |13.0
     Ever confirmed|0                           |1

--- Comment #1 from Paul Thomas <pault at gcc dot gnu.org> ---
8.3.1 20191027 runs through to the end of the program and then segfaults.

9.2.1 20191221 shows the same behaviour as mainline, as do all the branches in
between.

Thanks for the report

Paul

[Bug fortran/109066] Segfault when using defined assignment

[pault at gcc dot gnu.org]

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

--- Comment #2 from Paul Thomas <pault at gcc dot gnu.org> ---
Hi Andrew,

Thanks for the report. However, IMHO the code is invalid since the result of
hdf5Constructor is not defined.

  function hdf5Constructor() result(self)
    implicit none
    type(hdf5Object) :: self
    self = hdf5Object (resourceManager())
    return
  end function hdf5Constructor

works a treat.

If there is a requirement in the standard that a function result such as this
be initialised, I am unable to find it in the F2018 standard. 

Paul

[Bug fortran/109066] Segfault when using defined assignment

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |kargl at gcc dot gnu.org

--- Comment #3 from kargl at gcc dot gnu.org ---
(In reply to Paul Thomas from comment #2)
> Hi Andrew,
> 
> Thanks for the report. However, IMHO the code is invalid since the result of
> hdf5Constructor is not defined.
> 
>   function hdf5Constructor() result(self)
>     implicit none
>     type(hdf5Object) :: self
>     self = hdf5Object (resourceManager())
>     return
>   end function hdf5Constructor
> 
> works a treat.
> 
> If there is a requirement in the standard that a function result such as
> this be initialised, I am unable to find it in the F2018 standard. 
> 
> Paul

F2018, page 319.
If the function result is not a pointer, its value shall be defined by
the function.  If the function result is a pointer, on return the pointer
association status of the function result shall not be undefined.

[Bug fortran/109066] Segfault when using defined assignment

[paul.richard.thomas at gmail dot com]

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

--- Comment #4 from paul.richard.thomas at gmail dot com <paul.richard.thomas at gmail dot com> ---
Hi Steve,

Indeed - I found that paragraph shortly after writing. Thanks for posting
it.

Cheers

Paul


On Thu, 9 Mar 2023 at 15:33, kargl at gcc dot gnu.org <
gcc-bugzilla@gcc.gnu.org> wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109066
>
> kargl at gcc dot gnu.org changed:
>
>            What    |Removed                     |Added
>
> ----------------------------------------------------------------------------
>                  CC|                            |kargl at gcc dot gnu.org
>
> --- Comment #3 from kargl at gcc dot gnu.org ---
> (In reply to Paul Thomas from comment #2)
> > Hi Andrew,
> >
> > Thanks for the report. However, IMHO the code is invalid since the
> result of
> > hdf5Constructor is not defined.
> >
> >   function hdf5Constructor() result(self)
> >     implicit none
> >     type(hdf5Object) :: self
> >     self = hdf5Object (resourceManager())
> >     return
> >   end function hdf5Constructor
> >
> > works a treat.
> >
> > If there is a requirement in the standard that a function result such as
> > this be initialised, I am unable to find it in the F2018 standard.
> >
> > Paul
>
> F2018, page 319.
> If the function result is not a pointer, its value shall be defined by
> the function.  If the function result is a pointer, on return the pointer
> association status of the function result shall not be undefined.
>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.