[Bug fortran/98342] New: Allocatable component in call to assumed-rank routine causes invalid pointer

[Bug fortran/98342] New: Allocatable component in call to assumed-rank routine causes invalid pointer

[mscfd at gmx dot net]

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

            Bug ID: 98342
           Summary: Allocatable component in call to assumed-rank routine
                    causes invalid pointer
           Product: gcc
           Version: 11.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
          Assignee: unassigned at gcc dot gnu.org
          Reporter: mscfd at gmx dot net
  Target Milestone: ---

Created attachment 49784
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49784&action=edit
Fortran source code

The attached code aborts with
 *** Error in `./alloc_rank.x': munmap_chunk(): invalid pointer
after finishing the function call to "sel_rank". Necessary ingredients are a
derived type with an allocatable component and that the argument tuple of
"sel_rank" has assumed rank.

[Bug fortran/98342] Allocatable component in call to assumed-rank routine causes invalid pointer

[mscfd at gmx dot net]

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

--- Comment #1 from martin <mscfd at gmx dot net> ---
This does not the require the recent patch proposed for bug 97694 and bug
97723. It also fails with gfortran 10.1.0.

[Bug fortran/98342] Allocatable component in call to assumed-rank routine causes invalid pointer

[pault at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |pault at gcc dot gnu.org
     Ever confirmed|0                           |1
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2020-12-17
           Assignee|unassigned at gcc dot gnu.org      |pault at gcc dot gnu.org

--- Comment #2 from Paul Thomas <pault at gcc dot gnu.org> ---
Googling on munmap_chunk(): invalid pointer reveals that this is quite a
frequent problem.

It originates from the call

out = sel_rank(get_tuple(x))

rather than what happens in either function. Somewhere a free is bein done on
memory that is not malloc'ed.

Bizarrely,

out = sel_rank([get_tuple(x)])

as does

z = get_tuple(x) ! z appropriately declared of course!
out = sel_rank(z)

valgrind confirms this:
....snip....
==535157== Invalid free() / delete / delete[] / realloc()
==535157==    at 0x483A9F5: free (vg_replace_malloc.c:538)
==535157==    by 0x40343A: MAIN__ (pr98342.f90:48)
==535157==    by 0x4035BA: main (pr98342.f90:40)
==535157==  Address 0x1ffeffede0 is on thread 1's stack
==535157==  in frame #1, created by MAIN__ (pr98342.f90:39)
==535157== 
....snip....

The problem arises somewhere in trans-expr.c(gfc_conv_procedure_call).

I am on to it :-)

Paul

[Bug fortran/98342] Allocatable component in call to assumed-rank routine causes invalid pointer

[pault at gcc dot gnu.org]

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

--- Comment #3 from Paul Thomas <pault at gcc dot gnu.org> ---
Created attachment 49793
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49793&action=edit
Fix for the PR

This regtests OK. Testcase:

! { dg-do run }
!
! Test the fix for PR98342.
!
! Contributed by Martin Stein  <mscfd@gmx.net>
!
module mod
implicit none
private
public get_tuple, sel_rank

! we need to encapsulate the allocatable in a derived type
type, public :: tuple
   integer, dimension(:), allocatable :: t
! with pointer there is no failure
! integer, dimension(:), pointer :: t
end type tuple

contains

function sel_rank(x) result(s)
   character(len=:), allocatable :: s
   type(tuple), dimension(..), intent(in) :: x
   select rank (x)
   rank (0)
      s = '0'
   rank (1)
      s = '1'
   rank default
      s = '?'
   end select
! this is printed as expected
!   print *, 'rank: ', s
end function sel_rank

function get_tuple(t) result(a)
   type(tuple) :: a
   integer, dimension(:), intent(in) :: t
   allocate(a%t, source=t)
end function get_tuple

end module mod


program alloc_rank
   use mod
   implicit none

   integer, dimension(1:3) :: x
   character(len=:), allocatable :: output
   type(tuple) :: z

   x = [1,2,3]
! this should print '0' (as a tuple itself has rank 0)
   output = sel_rank(get_tuple(x))   ! runtime: Error in `./alloc_rank.x':
                                     ! munmap_chunk(): invalid pointer
                                     ! (memory freed not malloc'ed)
   if (output .ne. '0') stop 1

   output = sel_rank([get_tuple(x)]) ! This worked OK
   if (output .ne. '1') stop 2

   deallocate(output)
end program alloc_rank

Paul

[Bug fortran/98342] Allocatable component in call to assumed-rank routine causes invalid pointer

[mscfd at gmx dot net]

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

--- Comment #4 from martin <mscfd at gmx dot net> ---
Just checked the patch and it works great, except that I can now easily produce
an ICE by changing (in sel_rank)

   type(tuple), dimension(..), intent(in) :: x

to

   class(*), dimension(..), intent(in) :: x

The ICE is
fc_get_descriptor_field, at fortran/trans-array.c:140
0x613e94 gfc_get_descriptor_field
        ../../gcc-repo/gcc/fortran/trans-array.c:140
0x75cd35 gfc_conv_descriptor_data_get(tree_node*)
        ../../gcc-repo/gcc/fortran/trans-array.c:159
0x76b769 gfc_conv_array_data(tree_node*)
        ../../gcc-repo/gcc/fortran/trans-array.c:2985
0x76b769 structure_alloc_comps
        ../../gcc-repo/gcc/fortran/trans-array.c:8559
0x76d9ca gfc_deallocate_alloc_comp(gfc_symbol*, tree_node*, int, int)
        ../../gcc-repo/gcc/fortran/trans-array.c:9681
0x797535 gfc_conv_procedure_call(gfc_se*, gfc_symbol*, gfc_actual_arglist*,
gfc_expr*, vec<tree_node*, va_gc, vl_embed>*)
        ../../gcc-repo/gcc/fortran/trans-expr.c:6457
0x79088b gfc_trans_assignment_1
        ../../gcc-repo/gcc/fortran/trans-expr.c:10930
0x757f33 trans_code
        ../../gcc-repo/gcc/fortran/trans.c:1888
0x781504 gfc_generate_function_code(gfc_namespace*)
        ../../gcc-repo/gcc/fortran/trans-decl.c:6880
0x6fd5ce translate_all_program_units
        ../../gcc-repo/gcc/fortran/parse.c:6351
0x6fd5ce gfc_parse_file()
        ../../gcc-repo/gcc/fortran/parse.c:6620
0x75503f gfc_be_parse_file
        ../../gcc-repo/gcc/fortran/f95-lang.c:212


Not sure whether this is an entirely new problem or related to the patch. At
least trans-expr.c6457 is just about 20 lines below the place where the patch
add the lines.

[Bug fortran/98342] Allocatable component in call to assumed-rank routine causes invalid pointer

[cvs-commit at gcc dot gnu.org]

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

--- Comment #5 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Paul Thomas <pault@gcc.gnu.org>:

https://gcc.gnu.org/g:5159b88ef1a1774ec8851c6b92794ae2bf6e0b74

commit r11-7362-g5159b88ef1a1774ec8851c6b92794ae2bf6e0b74
Author: Paul Thomas <pault@gcc.gnu.org>
Date:   Wed Feb 24 16:00:51 2021 +0000

    Fortran: Fix memory problems with assumed rank formal args [PR98342].

    2021-02-24  Paul Thomas  <pault@gcc.gnu.org>

    gcc/fortran
            PR fortran/98342
            * trans-expr.c (gfc_conv_derived_to_class): Add optional arg.
            'derived_array' to hold the fixed, parmse expr in the case of
            assumed rank formal arguments. Deal with optional arguments.
            (gfc_conv_procedure_call): Null 'derived' array for each actual
            argument. Add its address to the call to gfc_conv_derived_to_
            class. Access the 'data' field of scalar descriptors before
            deallocating allocatable components. Also strip NOPs before the
            calls to gfc_deallocate_alloc_comp. Use 'derived' array as the
            input to gfc_deallocate_alloc_comp if it is available.
            * trans.h : Include the optional argument 'derived_array' to
            the prototype of gfc_conv_derived_to_class. The default value
            is NULL_TREE.

    gcc/testsuite/
            PR fortran/98342
            * gfortran.dg/assumed_rank_21.f90 : New test.

[Bug fortran/98342] Allocatable component in call to assumed-rank routine causes invalid pointer

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED

[Bug fortran/98342] Allocatable component in call to assumed-rank routine causes invalid pointer

[sandra at gcc dot gnu.org]

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

sandra at gcc dot gnu.org changed:

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

--- Comment #6 from sandra at gcc dot gnu.org ---
Has this bug been fully fixed now, so that we can close it?

[Bug fortran/98342] Allocatable component in call to assumed-rank routine causes invalid pointer

[dominiq at lps dot ens.fr]

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

--- Comment #7 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
> Has this bug been fully fixed now, so that we can close it?

It seems so.

[Bug fortran/98342] Allocatable component in call to assumed-rank routine causes invalid pointer

[mscfd at gmx dot net]

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

--- Comment #8 from martin <mscfd at gmx dot net> ---
Seems to work fine with current master. Not even valgrind complains.

[Bug fortran/98342] Allocatable component in call to assumed-rank routine causes invalid pointer

[sandra at gcc dot gnu.org]

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

sandra at gcc dot gnu.org changed:

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

--- Comment #9 from sandra at gcc dot gnu.org ---
Marking this as fixed.