[Bug fortran/41936] Memory leakage with allocatables and user-defined operators

[Bug fortran/41936] Memory leakage with allocatables and user-defined operators

[mikael at gcc dot gnu.org]

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

Mikael Morin <mikael at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |patch
                 CC|                            |mikael at gcc dot gnu.org

--- Comment #2 from Mikael Morin <mikael at gcc dot gnu.org> 2011-02-28 21:22:39 UTC ---
Fixed if one adds the code below (copied from gfc_conv_array_parameter).
I'm afraid this could change a memory leak into a double free (see PR 40850).
Also, not quite right (even if the middle-end optimizers are likely to fix it)
because it adds cleanup code to both foo and bar.

diff --git a/trans-expr.c b/trans-expr.c
index d6c1f9f..3919870 100644
--- a/trans-expr.c
+++ b/trans-expr.c
@@ -4900,6 +4900,19 @@ gfc_conv_expr_reference (gfc_se * se, gfc_expr * expr)

   /* Take the address of that value.  */
   se->expr = gfc_build_addr_expr (NULL_TREE, var);
+  if ((expr->ts.type == BT_DERIVED || expr->ts.type == BT_CLASS)
+      && expr->ts.u.derived->attr.alloc_comp
+      && expr->expr_type != EXPR_VARIABLE)
+    {
+      tree tmp;
+
+      tmp = build_fold_indirect_ref_loc (input_location, se->expr);
+      tmp = gfc_deallocate_alloc_comp (expr->ts.u.derived, tmp, expr->rank);
+      
+      /* The components shall be deallocated before
+         their containing entity.  */
+      gfc_prepend_expr_to_block (&se->post, tmp);
+    }
 }

[Bug fortran/41936] Memory leakage with allocatables and user-defined operators

[dominiq at lps dot ens.fr]

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

--- Comment #3 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
> Fixed if one adds the code below (copied from gfc_conv_array_parameter).
> I'm afraid this could change a memory leak into a double free (see PR 40850).
> Also, not quite right (even if the middle-end optimizers are likely to fix it) 
> because it adds cleanup code to both foo and bar.

With the patch in comment 2, the tests gfortran.dg/alloc_comp_basics_1.f90 and
gfortran.dg/alloc_comp_constructor_1.f90 fail because there are 21 occurrences
of "builtin_free". This is fixed by the following updated patch (against
r209838)

--- ../_clean/gcc/fortran/trans-expr.c    2014-04-25 14:30:23.000000000 +0200
+++ gcc/fortran/trans-expr.c    2014-04-27 16:03:28.000000000 +0200
@@ -6474,6 +6474,19 @@ gfc_conv_expr_reference (gfc_se * se, gf

   /* Take the address of that value.  */
   se->expr = gfc_build_addr_expr (NULL_TREE, var);
+  if ((expr->ts.type == BT_DERIVED || expr->ts.type == BT_CLASS)
+      && expr->ts.u.derived->attr.alloc_comp && expr->rank
+      && expr->expr_type != EXPR_VARIABLE)
+    {
+      tree tmp;
+
+      tmp = build_fold_indirect_ref_loc (input_location, se->expr);
+      tmp = gfc_deallocate_alloc_comp (expr->ts.u.derived, tmp, expr->rank);
+      
+      /* The components shall be deallocated before
+         their containing entity.  */
+      gfc_prepend_expr_to_block (&se->post, tmp);
+    }
 }

[Bug fortran/41936] Memory leakage with allocatables and user-defined operators

[burnus at gcc dot gnu.org]

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

--- Comment #4 from Tobias Burnus <burnus at gcc dot gnu.org> ---
(In reply to Dominique d'Humieres from comment #3)
> +  if ((expr->ts.type == BT_DERIVED || expr->ts.type == BT_CLASS)
> +      && expr->ts.u.derived->attr.alloc_comp && expr->rank
> +      && expr->expr_type != EXPR_VARIABLE)
> +    {
> +      tmp = build_fold_indirect_ref_loc (input_location, se->expr);
> +      tmp = gfc_deallocate_alloc_comp (expr->ts.u.derived, tmp, expr->rank);

Calling gfc_deallocate_alloc_comp for BT_CLASS looks wrong. You have to call
the finalization wrapper - to ensure that not only the allocatable components
of the declared type but also the ones of the effective/actual type are
deallocated. Additionally, that ensure that user's finalizer is called when it
exists.

(For BT_DERIVED, you may also have to call the finalization wrapper - but only
if the type has finalizers.)

[Bug fortran/41936] Memory leakage with allocatables and user-defined operators

[dominiq at lps dot ens.fr]

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

--- Comment #5 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
> Calling gfc_deallocate_alloc_comp for BT_CLASS looks wrong. ...

I have only added " && expr->rank" to the three year old Mikael's patch.

> You have to call the finalization wrapper - to ensure that not only the 
> allocatable components of the declared type but also the ones of the
> effective/actual type are deallocated. Additionally, that ensure that
> user's finalizer is called when it exists.
>
> (For BT_DERIVED, you may also have to call the finalization wrapper - but only
> if the type has finalizers.)

Could you please provide a more explicit pointer?

[Bug fortran/41936] Memory leakage with allocatables and user-defined operators

[dominiq at lps dot ens.fr]

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

--- Comment #6 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
Is the following patch OK?

--- ../_clean/gcc/fortran/trans-expr.c    2014-04-30 21:41:33.000000000 +0200
+++ gcc/fortran/trans-expr.c    2014-05-04 00:42:50.000000000 +0200
@@ -6504,6 +6504,20 @@ gfc_conv_expr_reference (gfc_se * se, gf

   /* Take the address of that value.  */
   se->expr = gfc_build_addr_expr (NULL_TREE, var);
+  if (expr->ts.type == BT_DERIVED && expr->rank
+      && !gfc_is_finalizable (expr->ts.u.derived, NULL)
+      && expr->ts.u.derived->attr.alloc_comp
+      && expr->expr_type != EXPR_VARIABLE)
+    {
+      tree tmp;
+
+      tmp = build_fold_indirect_ref_loc (input_location, se->expr);
+      tmp = gfc_deallocate_alloc_comp (expr->ts.u.derived, tmp, expr->rank);
+      
+      /* The components shall be deallocated before
+         their containing entity.  */
+      gfc_prepend_expr_to_block (&se->post, tmp);
+    }
 }


It fixes the memory leaks for the test in comment 0 and for
gfortran.dg/class_array_15.f03, but not pr55603 nor pr60913.

Is the following change for gfortran.dg/class_array_15.f03

--- ../_clean/gcc/testsuite/gfortran.dg/class_array_15.f03    2013-01-06
22:34:50.000000000 +0100
+++ gcc/testsuite/gfortran.dg/class_array_15.f03    2014-05-04
10:24:06.000000000 +0200
@@ -1,4 +1,5 @@
 ! { dg-do run }
+! { dg-options "-fdump-tree-original" }
 !
 ! Tests the fixes for three bugs with the same underlying cause.  All are
regressions
 ! that come about because class array elements end up with a different tree
type
@@ -114,3 +115,5 @@ subroutine pr54992  ! This test remains 
   bh => bhGet(b,instance=2)
   if (loc (b) .ne. loc(bh%hostNode)) call abort
 end
+! { dg-final { scan-tree-dump-times "builtin_free" 12 "original" } }
+! { dg-final { cleanup-tree-dump "original" } }

enough (there are only 11 builtin_free without the patch)? or should I add the
test in comment 0 (15 builtin_free with the patch, 12 without)?

[Bug fortran/41936] Memory leakage with allocatables and user-defined operators

[dominiq at gcc dot gnu.org]

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

--- Comment #7 from dominiq at gcc dot gnu.org ---
Author: dominiq
Date: Tue Jun 10 11:42:38 2014
New Revision: 211405

URL: http://gcc.gnu.org/viewcvs?rev=211405&root=gcc&view=rev
Log:
2014-06-10  Dominique d'Humieres <dominiq@lps.ens.fr>
        Mikael Morin <mikael@gcc.gnu.org>

    PR fortran/41936
gcc/fortran/
    * trans-expr.c (gfc_conv_expr_reference): Deallocate array
    components.

gcc/testsuite/
    * gfortran.dg/class_array_15.f03: Check memory leaks.


Modified:
    trunk/gcc/fortran/ChangeLog
    trunk/gcc/fortran/trans-expr.c
    trunk/gcc/testsuite/ChangeLog
    trunk/gcc/testsuite/gfortran.dg/class_array_15.f03

[Bug fortran/41936] Memory leakage with allocatables and user-defined operators

[dominiq at gcc dot gnu.org]

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

--- Comment #8 from dominiq at gcc dot gnu.org ---
Author: dominiq
Date: Mon Jul  7 12:32:37 2014
New Revision: 212329

URL: https://gcc.gnu.org/viewcvs?rev=212329&root=gcc&view=rev
Log:
2014-07-07  Dominique d'Humieres <dominiq@lps.ens.fr>
        Mikael Morin <mikael@gcc.gnu.org>

    PR fortran/41936
gcc/fortran/
    * trans-expr.c (gfc_conv_expr_reference): Deallocate array
    components.

gcc/testsuite/
    * gfortran.dg/class_array_15.f03: Check memory leaks.


Modified:
    branches/gcc-4_9-branch/gcc/fortran/ChangeLog
    branches/gcc-4_9-branch/gcc/fortran/trans-expr.c
    branches/gcc-4_9-branch/gcc/testsuite/ChangeLog
    branches/gcc-4_9-branch/gcc/testsuite/gfortran.dg/class_array_15.f03

[Bug fortran/41936] Memory leakage with allocatables and user-defined operators

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres <dominiq at lps dot ens.fr> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Assignee|pault at gcc dot gnu.org           |dominiq at lps dot ens.fr

--- Comment #9 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
Fixed on 4.9.1 and trunk (4.10.0).

[Bug fortran/41936] Memory leakage with allocatables and user-defined operators

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres <dominiq at lps dot ens.fr> changed:

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

--- Comment #10 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
Closing.

[Bug fortran/41936] New: Memory leakage with allocatables and user-defined operators

[burnus at gcc dot gnu dot org]

Reported by Paul van Delst at
http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/196e69ca0ed38f98

Seemingly, gfortran leaks memory with allocatables and user-defined operators.
Might be a duplicate of some other bug - I have not yet check thoroughly. I
also have not checked the code myself. 

!<-----begin module my_type_define----->
module my_type_define
  implicit none

  private
  public :: my_type
  public :: assignment(=)
  public :: operator(+)
  public :: my_associated
  public :: my_destroy
  public :: my_create
  public :: my_inspect

  interface assignment(=)
    module procedure my_assign
  end interface assignment(=)
  interface operator(+)
    module procedure my_add
  end interface operator(+)

  type :: my_type
    integer :: n = 0
    real, allocatable :: x(:), y(:), z(:)
  end type my_type

contains

  ! Public

  elemental function my_associated( my ) result( status )
    type(my_type), intent(in) :: my
    logical :: status
    ! test the structure members
    status = allocated(my%x) .or. allocated(my%y) .or. allocated(my%z)
  end function my_associated

  elemental subroutine my_destroy( my )
    type(my_type), intent(out) :: my
  end subroutine my_destroy

  elemental subroutine my_create( my, n )
    type(my_type), intent(out) :: my
    integer,       intent(in)  :: n
    integer :: alloc_stat
    ! check input
    if ( n < 1 ) return
    ! perform the allocation
    allocate( my%x(n), my%y(n), my%z(n), stat=alloc_stat )
    ! initialise
    if ( alloc_stat == 0 ) then
      ! ...dimension
      my%n = n
      ! ...arrays
      my%x = 0.0
      my%y = 0.0
      my%z = 0.0
    end if
  end subroutine my_create

  subroutine my_inspect( my )
    type(my_type), intent(in) :: my
    if ( .not. my_associated( my ) ) return
    write(*,'(5x,"x:")'); write(*,'(5(1x,es13.6))') my%x
    write(*,'(5x,"y:")'); write(*,'(5(1x,es13.6))') my%y
    write(*,'(5x,"z:")'); write(*,'(5(1x,es13.6))') my%z
  end subroutine my_inspect

  ! Private

  elemental subroutine my_assign( copy, original )
    type(my_type),  intent(out) :: copy
    type(my_type),  intent(in)  :: original
    ! if input structure not used, do nothing
    if ( .not. my_associated( original ) ) return
    ! create the output structure
    call my_create( copy, original%n )
    ! ...return if no allocation performed
    if ( .not. my_associated( copy ) ) return
    ! copy data
    copy%x = original%x
    copy%y = original%y
    copy%z = original%z
  end subroutine my_assign

  elemental function my_add( my1, my2 ) result( mysum )
    type(my_type), intent(in) :: my1, my2
    type(my_type) :: mysum
    ! copy the first structure
    mysum = my1
    ! and add its components to the second one
    mysum%x = mysum%x + my2%x
    mysum%y = mysum%y + my2%y
    mysum%z = mysum%z + my2%z
  end function my_add

end module my_type_define
!<-----end module my_type_define----->

!<-----begin program my_test----->
program my_test
  use my_type_define
  implicit none

  integer, parameter :: n = 3

  integer :: i
  type(my_type) :: a, b
  type(my_type) :: c(n), d(n)

  ! Scalar test
  call my_create(a, 10)
  a%x = 1.0
  a%y = 2.0
  a%z = 3.0
  write(*,'(/,"A")')
  call my_inspect(a)
  b = a
  write(*,'(/,"B")')
  call my_inspect(b)
  a = a + b
  write(*,'(/,"A = A + B")')
  call my_inspect(a)
  call my_destroy(a)
  call my_destroy(b)

  ! Rank-1 test
  call my_create(c, 10)
  do i = 1, n
    c(i)%x = 1.0
    c(i)%y = 2.0
    c(i)%z = 3.0
    write(*,'(/,"C(",i0,")")') i
    call my_inspect(c(i))
  end do
  d = c
  do i = 1, n
    write(*,'(/,"D(",i0,")")') i
    call my_inspect(d(i))
  end do
  c = c + d  ! commenting this line makes memory leaks go away.
  do i = 1, n
    write(*,'(/,"C(",i0,") + D(",i0,")")') i, i
    call my_inspect(c(i))
  end do
  call my_destroy(c)
  call my_destroy(d)
end program my_test
!<-----end program my_test----->

!<-----begin valgrind output----->
==356==
==356== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 17 from 1)
==356== malloc/free: in use at exit: 360 bytes in 9 blocks.
==356== malloc/free: 146 allocs, 137 frees, 225,998 bytes allocated.
==356== For counts of detected errors, rerun with: -v
==356== searching for pointers to 9 not-freed blocks.
==356== checked 70,540 bytes.
==356==
==356== 120 bytes in 3 blocks are definitely lost in loss record 1 of 3
==356==    at 0x40053C0: malloc (vg_replace_malloc.c:149)
==356==    by 0x804921F: __my_type_define_MOD_my_create (in a.out)
==356==    by 0x8048AE0: __my_type_define_MOD_my_assign (in a.out)
==356==    by 0x80486C6: __my_type_define_MOD_my_add (in a.out)
==356==    by 0x8049E64: MAIN__ (in a.out)
==356==    by 0x804A20A: main (fmain.c:21)
==356==
==356==
==356== 120 bytes in 3 blocks are definitely lost in loss record 2 of 3
==356==    at 0x40053C0: malloc (vg_replace_malloc.c:149)
==356==    by 0x804912A: __my_type_define_MOD_my_create (in a.out)
==356==    by 0x8048AE0: __my_type_define_MOD_my_assign (in a.out)
==356==    by 0x80486C6: __my_type_define_MOD_my_add (in a.out)
==356==    by 0x8049E64: MAIN__ (in a.out)
==356==    by 0x804A20A: main (fmain.c:21)
==356==
==356==
==356== 120 bytes in 3 blocks are definitely lost in loss record 3 of 3
==356==    at 0x40053C0: malloc (vg_replace_malloc.c:149)
==356==    by 0x8049035: __my_type_define_MOD_my_create (in a.out)
==356==    by 0x8048AE0: __my_type_define_MOD_my_assign (in a.out)
==356==    by 0x80486C6: __my_type_define_MOD_my_add (in a.out)
==356==    by 0x8049E64: MAIN__ (in a.out)
==356==    by 0x804A20A: main (fmain.c:21)
==356==
==356== LEAK SUMMARY:
==356==    definitely lost: 360 bytes in 9 blocks.
==356==      possibly lost: 0 bytes in 0 blocks.
==356==    still reachable: 0 bytes in 0 blocks.
==356==         suppressed: 0 bytes in 0 blocks.
!<-----end valgrind output----->


-- 
           Summary: Memory leakage with allocatables and user-defined
                    operators
           Product: gcc
           Version: 4.5.0
            Status: UNCONFIRMED
          Keywords: wrong-code
          Severity: normal
          Priority: P3
         Component: fortran
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: burnus at gcc dot gnu dot org


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

[Bug fortran/41936] Memory leakage with allocatables and user-defined operators

[pault at gcc dot gnu dot org]

------- Comment #1 from pault at gcc dot gnu dot org  2009-11-12 13:50 -------
The testcase segfaults on the a = a + b and the c = c + d on Cygwin.  On FC8
i386, valgrind does not show any problem with either and the testprogramme runs
to completion!

However, moving a = a + b to subroutine foo and c = c+ d to subroutine bar
isolates the source of the problem.

bar ()
{
  {
    integer(kind=4) S.23;

    S.23 = 1;
    while (1)
      {
        if (S.23 > 3) goto L.11;
        {
          struct my_type D.1542;

          D.1542 = my_add (&c[S.23 + -1], &d[S.23 + -1]);
          my_assign (&c[S.23 + -1], &D.1542);
        }
        S.23 = S.23 + 1;
      }
    L.11:;
  }
}


foo ()
{
  {
    struct my_type D.1547;

    D.1547 = my_add (&a, &b);
    my_assign (&a, &D.1547);
    if (D.1547.x.data != 0B)
      {
        __builtin_free ((void *) D.1547.x.data);
      }
    D.1547.x.data = 0B;
    if (D.1547.y.data != 0B)
      {
        __builtin_free ((void *) D.1547.y.data);
      }
    D.1547.y.data = 0B;
    if (D.1547.z.data != 0B)
      {
        __builtin_free ((void *) D.1547.z.data);
      }
    D.1547.z.data = 0B;
  }
}

Most of the right allocating and freeing goes on in 'my_add' and 'my_assign'. 
However, whilst 'foo' (scalar) frees the allocatable components of the
temporary D.1547, the same is not true for D.1542 in 'bar' (array).

This loses (n = 3) x (4 bytes) x (3 components) x (dim = 10) = 360 bytes.

The problem, therefore, lies in the scalarization of the elemental call to
'my_add', where the deallocation of the temporary goes walkabout.  If I would
hazard a guess, without looking, I would say that the post-block for the scalar
assignment has not been incorporated in the loop body.

Paul


-- 

pault at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|unassigned at gcc dot gnu   |pault at gcc dot gnu dot org
                   |dot org                     |
             Status|UNCONFIRMED                 |ASSIGNED
     Ever Confirmed|0                           |1
   Last reconfirmed|0000-00-00 00:00:00         |2009-11-12 13:50:59
               date|                            |


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