[Bug fortran/49466] New: Memory leak with assignment of extended derived types

[Bug fortran/49466] New: Memory leak with assignment of extended derived types

[townsend at astro dot wisc.edu]

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

           Summary: Memory leak with assignment of extended derived types
           Product: gcc
           Version: 4.7.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: townsend@astro.wisc.edu


Created attachment 24558
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24558
Sample code reproducing the problem

I've encountered a severe memory leak in one of my codes, which I've been able
to trace back to an issue with the assignment of extended derived types
containing allocatable arrays.

It seems as though any allocatable components of the *parent* type are not
properly deallocated in a variable that appears on the lhs of an assignment
(whether default or defined). 

In the attached sample code, which is a reduced test case from the full code,
the assignment "as_b = as_a" leaks memory from the U(:) allocatable component
(which is defined in state_t, the parent type), but not from the W(:)
allocatable component (which is defined in astate_t).

[Bug fortran/49466] Memory leak with assignment of extended derived types

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

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

--- Comment #1 from janus at gcc dot gnu.org 2011-06-19 15:27:55 UTC ---
(In reply to comment #0)
> In the attached sample code, which is a reduced test case from the full code,
> the assignment "as_b = as_a" leaks memory from the U(:) allocatable component
> (which is defined in state_t, the parent type), but not from the W(:)
> allocatable component (which is defined in astate_t).

Sorry, I'm not able to reproduce the memory leak with gfortran version 4.5 and
valgrind. Could you please tell me which gfortran version you use and how you
detect the memory leak?

[Bug fortran/49466] Memory leak with assignment of extended derived types

[townsend at astro dot wisc.edu]

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

--- Comment #2 from Rich Townsend <townsend at astro dot wisc.edu> 2011-06-19 15:39:28 UTC ---
(In reply to comment #1)
> (In reply to comment #0)
> > In the attached sample code, which is a reduced test case from the full code,
> > the assignment "as_b = as_a" leaks memory from the U(:) allocatable component
> > (which is defined in state_t, the parent type), but not from the W(:)
> > allocatable component (which is defined in astate_t).
> 
> Sorry, I'm not able to reproduce the memory leak with gfortran version 4.5 and
> valgrind. Could you please tell me which gfortran version you use and how you
> detect the memory leak?

This is 4.7.0 (svn) running on OS X 10.6.7. valgrind output:


==32629== Memcheck, a memory error detector
==32629== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al.
==32629== Using Valgrind-3.6.0 and LibVEX; rerun with -h for copyright info
==32629== Command: ./evolve_aflow
==32629== 
--32629-- ./evolve_aflow:
--32629-- dSYM directory is missing; consider using --dsymutil=yes
==32629== 
==32629== HEAP SUMMARY:
==32629==     in use at exit: 4,004,088 bytes in 1,002 blocks
==32629==   total heap usage: 2,019 allocs, 1,017 frees, 8,012,001 bytes
allocated
==32629== 
==32629== 3,996,000 bytes in 999 blocks are definitely lost in loss record 4 of
4
==32629==    at 0x10001079F: malloc (vg_replace_malloc.c:236)
==32629==    by 0x100000C27: MAIN__ (in ./evolve_aflow)
==32629==    by 0x100000DA2: main (in ./evolve_aflow)
==32629== 
==32629== LEAK SUMMARY:
==32629==    definitely lost: 3,996,000 bytes in 999 blocks
==32629==    indirectly lost: 0 bytes in 0 blocks
==32629==      possibly lost: 0 bytes in 0 blocks
==32629==    still reachable: 8,088 bytes in 3 blocks
==32629==         suppressed: 0 bytes in 0 blocks
==32629== Reachable blocks (those to which a pointer was found) are not shown.
==32629== To see them, rerun with: --leak-check=full --show-reachable=yes
==32629== 
==32629== For counts of detected and suppressed errors, rerun with: -v
==32629== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)

[Bug fortran/49466] Memory leak with assignment of extended derived types

[dominiq at lps dot ens.fr]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2011.06.19 15:51:25
     Ever Confirmed|0                           |1

--- Comment #3 from Dominique d'Humieres <dominiq at lps dot ens.fr> 2011-06-19 15:51:25 UTC ---
I see (with valgrind on x86_64-apple-darwin10) the memory leak for gcc 4.6
(revision 166102) and trunk, but not for gcc 4.5.2 or 4.6 revision 162456.

[Bug fortran/49466] [4.6/4.7 Regression] Memory leak with assignment of extended derived types

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|Memory leak with assignment |[4.6/4.7 Regression] Memory
                   |of extended derived types   |leak with assignment of
                   |                            |extended derived types

--- Comment #4 from janus at gcc dot gnu.org 2011-06-19 17:52:35 UTC ---
(In reply to comment #3)
> I see (with valgrind on x86_64-apple-darwin10) the memory leak for gcc 4.6
> (revision 166102) and trunk, but not for gcc 4.5.2 or 4.6 revision 162456.

Ok, I can also reproduce the memory leak with gfortran 4.7 on
x86_64-unknown-linux-gnu, which means that it is a regression.

Here is a reduced test case:


program evolve_aflow

  implicit none

  type :: state_t
     real, allocatable :: U(:)
  end type state_t

  type, extends(state_t) :: astate_t
  end type astate_t

  type(astate_t) :: a,b

  allocate(a%U(1000))

  b = a
  b = a

end program


In the first assignment b.U is allocated, in the second assignment it is not
freed, before being allocated again.

In fact, the dump does not contain a single "__builtin_free", while with 4.5 it
has six.

valgrind says:

==27163== 4,000 bytes in 1 blocks are definitely lost in loss record 3 of 3
==27163==    at 0x4C2683D: malloc (in
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==27163==    by 0x4009BC: MAIN__ (test.f90:16)
==27163==    by 0x400B9D: main (test.f90:19)

[Bug fortran/49466] [4.6/4.7 Regression] Memory leak with assignment of extended derived types

[dominiq at lps dot ens.fr]

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

--- Comment #5 from Dominique d'Humieres <dominiq at lps dot ens.fr> 2011-06-19 18:45:09 UTC ---
> In the first assignment b.U is allocated, in the second assignment it is not
> freed, before being allocated again.

I don't think it should be freed then allocated for the second assignment in
the code in comment#4.

[Bug fortran/49466] [4.6/4.7 Regression] Memory leak with assignment of extended derived types

[townsend at astro dot wisc.edu]

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

--- Comment #6 from Rich Townsend <townsend at astro dot wisc.edu> 2011-06-19 18:57:40 UTC ---
(In reply to comment #5)
> > In the first assignment b.U is allocated, in the second assignment it is not
> > freed, before being allocated again.
> 
> I don't think it should be freed then allocated for the second assignment in
> the code in comment#4.

Certainly, given that the lhs array component is the same shape as the rhs
array component, an optimization would be not to free and then allocate the
array prior to the copy.

However, that doesn't alter the fact that the behavior should be *as if* the
lhs array component were freed and then allocated with the appropriate shape.
This behavior has been in Fortran since TR 15581, which first introduced 
allocatable derived-type components as an extension to Fortran 95.

[Bug fortran/49466] [4.6/4.7 Regression] Memory leak with assignment of extended derived types

[dominiq at lps dot ens.fr]

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

--- Comment #7 from Dominique d'Humieres <dominiq at lps dot ens.fr> 2011-06-20 06:21:27 UTC ---
This is due to revision 165973:

Author:    janus
Date:    Tue Oct 26 17:38:42 2010 UTC (7 months, 3 weeks ago)
Changed paths:    10
Log Message:    
2010-10-26  Janus Weil  <janus@gcc.gnu.org>

    PR fortran/42647
    * trans.h (gfc_deallocate_scalar_with_status): New prototype.
    * trans.c (gfc_deallocate_scalar_with_status): New function for
    deallocation of allocatable scalars.
    * trans-array.c (structure_alloc_comps): Call it here ...
    * trans-decl.c (gfc_trans_deferred_vars): ... here ...
    * trans-stmt.c (gfc_trans_deallocate): ... and here.

2010-10-26  Janus Weil  <janus@gcc.gnu.org>

    PR fortran/42647
    * gfortran.dg/allocatable_scalar_9.f90: Extended.
    * gfortran.dg/allocatable_scalar_10.f90: New.
    * gfortran.dg/class_19.f03: Extended.

Another test:

program evolve_aflow

  implicit none

  type :: state_t
     real, allocatable :: U(:)
  end type state_t

  type, extends(state_t) :: astate_t
  end type astate_t

  type(astate_t) :: a,b

  allocate(a%U(1000))
  allocate(b%U(1000))

!  b%U = a%U
  a = b

  deallocate(a%U, b%U)

end program

[Bug fortran/49466] [4.6/4.7 Regression] Memory leak with assignment of extended derived types

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
         AssignedTo|unassigned at gcc dot       |janus at gcc dot gnu.org
                   |gnu.org                     |

--- Comment #8 from janus at gcc dot gnu.org 2011-06-27 17:33:19 UTC ---
(In reply to comment #7)
> This is due to revision 165973:


... and fixed by a partial revert of this commit (see below), which is free of
testsuite regressions. Will commit as obvious soon (unfortunately too late for
the 4.6.1 release).


Index: gcc/testsuite/gfortran.dg/allocatable_scalar_9.f90
===================================================================
--- gcc/testsuite/gfortran.dg/allocatable_scalar_9.f90    (revision 175536)
+++ gcc/testsuite/gfortran.dg/allocatable_scalar_9.f90    (working copy)
@@ -49,7 +49,7 @@ if(allocated(na3%b3)) call abort()
 if(allocated(na4%b4)) call abort()
 end

-! { dg-final { scan-tree-dump-times "__builtin_free" 32 "original" } }
+! { dg-final { scan-tree-dump-times "__builtin_free" 38 "original" } }
 ! { dg-final { cleanup-tree-dump "original" } }

 ! { dg-final { cleanup-modules "m" } }
Index: gcc/fortran/trans-array.c
===================================================================
--- gcc/fortran/trans-array.c    (revision 175536)
+++ gcc/fortran/trans-array.c    (working copy)
@@ -6682,18 +6682,22 @@ structure_alloc_comps (gfc_symbol * der_type, tree
       switch (purpose)
     {
     case DEALLOCATE_ALLOC_COMP:
+      if (cmp_has_alloc_comps && !c->attr.pointer)
+        {
+          /* Do not deallocate the components of ultimate pointer
+         components.  */
+          comp = fold_build3_loc (input_location, COMPONENT_REF, ctype,
+                      decl, cdecl, NULL_TREE);
+          rank = c->as ? c->as->rank : 0;
+          tmp = structure_alloc_comps (c->ts.u.derived, comp, NULL_TREE,
+                       rank, purpose);
+          gfc_add_expr_to_block (&fnblock, tmp);
+        }
+
       if (c->attr.allocatable && c->attr.dimension)
         {
           comp = fold_build3_loc (input_location, COMPONENT_REF, ctype,
                       decl, cdecl, NULL_TREE);
-          if (cmp_has_alloc_comps && !c->attr.pointer)
-        {
-          /* Do not deallocate the components of ultimate pointer
-             components.  */
-          tmp = structure_alloc_comps (c->ts.u.derived, comp, NULL_TREE,
-                           c->as->rank, purpose);
-          gfc_add_expr_to_block (&fnblock, tmp);
-        }
           tmp = gfc_trans_dealloc_allocated (comp);
           gfc_add_expr_to_block (&fnblock, tmp);
         }

[Bug fortran/49466] [4.6/4.7 Regression] Memory leak with assignment of extended derived types

[janus at gcc dot gnu.org]

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

--- Comment #9 from janus at gcc dot gnu.org 2011-06-27 20:59:16 UTC ---
Author: janus
Date: Mon Jun 27 20:59:12 2011
New Revision: 175563

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=175563
Log:
2011-06-27  Janus Weil  <janus@gcc.gnu.org>

    PR fortran/49466
    * trans-array.c (structure_alloc_comps): Make sure sub-components
    and extended types are correctly deallocated.


2011-06-27  Janus Weil  <janus@gcc.gnu.org>

    PR fortran/49466
    * gfortran.dg/allocatable_scalar_9.f90: Modified.
    * gfortran.dg/extends_14.f03: Modified.

Added:
    trunk/gcc/testsuite/gfortran.dg/extends_14.f03
Modified:
    trunk/gcc/fortran/ChangeLog
    trunk/gcc/fortran/trans-array.c
    trunk/gcc/testsuite/ChangeLog
    trunk/gcc/testsuite/gfortran.dg/allocatable_scalar_9.f90

[Bug fortran/49466] [4.6/4.7 Regression] Memory leak with assignment of extended derived types

[janus at gcc dot gnu.org]

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

--- Comment #10 from janus at gcc dot gnu.org 2011-07-02 13:46:23 UTC ---
Author: janus
Date: Sat Jul  2 13:46:21 2011
New Revision: 175780

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=175780
Log:
2011-07-02  Janus Weil  <janus@gcc.gnu.org>

    PR fortran/49466
    * trans-array.c (structure_alloc_comps): Make sure sub-components
    and extended types are correctly deallocated.


2011-07-02  Janus Weil  <janus@gcc.gnu.org>

    PR fortran/49466
    * gfortran.dg/allocatable_scalar_9.f90: Modified.
    * gfortran.dg/extends_14.f03: New.

Added:
    branches/gcc-4_6-branch/gcc/testsuite/gfortran.dg/extends_14.f03
Modified:
    branches/gcc-4_6-branch/gcc/fortran/ChangeLog
    branches/gcc-4_6-branch/gcc/fortran/trans-array.c
    branches/gcc-4_6-branch/gcc/testsuite/ChangeLog
    branches/gcc-4_6-branch/gcc/testsuite/gfortran.dg/allocatable_scalar_9.f90

[Bug fortran/49466] [4.6/4.7 Regression] Memory leak with assignment of extended derived types

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

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

--- Comment #11 from janus at gcc dot gnu.org 2011-07-02 13:52:18 UTC ---
Fixed on trunk and the 4.6 branch. This means that the fix will be part of the
upcoming release 4.6.2, which is tentatively scheduled for September.

Thanks for reporting, Rich!